Joe Merante, a 2012 Code for America Fellow, recently proposed a thought experiment about what he terms the “Civic Stack.” His thoughts resonate with me.
As a software developer, I reason about technology solutions in terms of a “stack.” That is, a stack describes the layers of technology, their discrete roles in the solution, and how these layered components coordinate and collaborate to produce the solution.
One of the most commonly taken-for-granted stacks is the Internet protocol stack, which is entirely ubiquitous by now, and Mr. Merante uses as his canonical example. Through it, the different abstraction layers enable rapid innovation and the emergence of new commerce channels and means of engagement and communication. Through it, the likes of Google, Amazon, Facebook, and Twitter sprang into existence. And through it they thrive.
Mr. Merante asks us to contrast these rapid innovations with government, which is “often criticized for being independent silos of operation and information.” Say what you want about the aforementioned organizations’ policies on information siloing, what enabled these organizations is re-usable software stacks.
Mr. Merante goes on to propose:
…A thought experiment in how we can come up with new approaches to work in the gov 2.0 space. It is an oversimplified and slightly arbitrary approximation to help analyze the impact and scope of our work in each layer and across layers. I encourage you to create new application ideas or provoke discussion by expanding and rearranging these layers.
The Civic Stack
The “Civic Stack” is defined as:
- Maintenance, Operations
- Property, Recordkeeping
- Emergency, Police, Fire
I believe Mr. Merante is presenting a classification of fundamental application types upon which other, higher-level applications build upon. In other words, a municipality should lay a core with these four capabilities and other applications build out of these by exposed, re-usable components.
Later, Mr. Merante concludes with:
Notably, I did not include… open data in any of the layers. That is because I see them more as features than products… In some ways, this is the flip side of the understanding that transparency alone is not enough. I’ve struggled this year in deciding whether open government needs to come from the top down or bottom up, and have worked to encourage both… I’d argue that the changes we’ve seen from the bottom up have pushed things along faster and farther, because they’ve come from identifying specific outcomes.
Mr. Merante is ambiguous on what he means by “top down or bottom up.” I cannot exactly tell if top/bottom refer to government/citizen (as in citizens forming brigades to implement the apps they want) or “Open Data API”/app. In the context of “transparency alone is not enough,” I think he is arguing that the “build [Open Data APIs] and [the apps] will come” mindset does not produce results as fast as good as targeting a specific use case and driving towards it. This resonates with me. I especially and strongly believe in exposing service endpoints, but understand that specific applications, or use cases, will deliver the best and most meaningful results.
Services at Amazon
According to former Amazon employee Steve Yegge, Amazon CEO Jeff Bezos issued a “Big Mandate” in the early 2000′s that changed Amazon’s technology stack. It positioned Amazon for greater internal re-usability and ease of deployment. Further, it ultimately allowed Amazon to enter into a new revenue market by re-selling their technology stack in the form of Amazon Web Services and other initiatives. Bezos’ “Big Mandate” is reportedly as follows:
- All teams will henceforth expose their data and functionality through service interfaces.
- Teams must communicate with each other through these interfaces.
- There will be no other form of interprocess communication allowed: …no direct reads from another team’s data store, …no back-doors back-doors whatsoever. The only communication allowed is via service interface calls over the network.
- It doesn’t matter what technology they use…
- All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
- Anyone who doesn’t do this will be fired.
Again, these mandates positioned Amazon to expose their internals in unprecedented ways. It provided them a competitive advantage and opened new revenue models. In government, there is, or rather should be, no competition. Only collaboration. Collaboration with its citizens, other municipalities and governments, and the developers that can leverage these new public services in meaningful ways.
Imagine if municipalities adopted such a mandate as core to their role as public servants.
A “New Public Service”
The previous decade was a period of enormous private commerce growth on the Internet. This next decade is the public sector’s moment. We are seeing and will continue to see a swing towards open data and citizen engagement from governments. It is time we start thinking about our governments’ technology stacks as a “New Public Service”:
- All governments will henceforth expose their data and functionality through service interfaces.
- It doesn’t matter what technology is used so long as it is reliably consumable.
- Service interfaces should be designed from the ground up to be externalizable. That is to say, government must plan and design to be able to expose the interface to developer citizens in the outside world.
As citizens, we already own the data. In many respects, we also own the technology itself. We must encourage our governments to adopt a mindset similar to Bezos’ “Big Mandate.” Let’s make government open by default with a “New Public Service.”
NOTE: Another discussion could be had about what data should be exposed and what should be protected. This is a sensitive topic and one that deserves attention and deep consideration.