Shelby Switzer is a fellow at the Beeck Center for Social Impact and Innovation at Georgetown University in DC in the US. My background is in civic technology, APIs, and data infrastructure. In this article, Shelby discusses how APIs can transform nations.
I lead the inter-governmental software collaborative (IOC). This is essentially a research and practice-oriented project. We work with students, have staff members, a community manager, and a researcher.
Hypothesis at IOC
Collaborating with other jurisdictions, by default, will save governments time and money while also increasing the likelihood of project success, the quality of the end solution, and customer satisfaction ratings from the public.
In government, we should care about how the public feels about our services. Our goal is to make the right thing (collaboration by default) the easy thing to do. We do that with research, storytelling, advocacy, and community and capacity building.
Let us talk about the status quo. We can see maybe how bad the situation is in most places. Let us start at the city level. Cities can do lots of things. Here are a few examples of what a city could do. Some cities might have public utilities like they manage your water system. Most of them are still tracking COVID cases and also vaccine uptake. They might also monitor and manage vacant properties as part of their code enforcement work. And then there’s also social services, for example, helping families find affordable childcare. But what one city does is not unique. Another city in the country is probably doing all the same things, maybe with a little bit of variation in terms of the policy.
While cities often have similar functions, the technology helping deliver those services and those functions for the public is very different. Some might have a SaaS system, while some may build a customized Dashboard. All of these systems are super complex. There is a huge diversity in the ecosystem and landscape, even within a city, much less across cities.
But let us think about this from a user perspective. What does the public think when trying to interact with the city? Let us consider an example. Let us say a user (Me) was laid off during COVID. I need help finding childcare so I can return to work. I also never know when childcare facilities will be closed because of high case counts in my area.
Meanwhile, I’m behind on my utility bill payments because I was laid off. I do not know what is happening behind the scenes. I don’t know about the internal services happening with the Social Services team or the childcare social worker I’m working with. In this scenario, as a user, I have to figure all that out somehow by myself. This isn’t very good for a user and the public trying to work with the government. Ultimately, the public doesn’t understand the city’s complexity, and they also don’t care about it. That’s not their job. They’re not public policy experts or city administrators.
This might sound familiar to an API audience because when we talk about this concept, we talk about users and systems. Users don’t care about systems’ complexity; even if they want to, they may not understand it.
All this is within a city. Imagine the experience if a person has to move to a different city. These issues also exist at the province, state, and country levels.
So, we have two problems. We have a core infrastructure software problem where we have software built by many different vendors. The financial cost for these different systems doesn’t make sense. It varies widely across jurisdictions based on your relationship with the vendor or your knowledge of procurement, acquisition, and technology.
The other issue is the data transfer layer issue. We must share and transfer data between cities, states, and countries.
To solve this, a good idea is to have shared infrastructure and services, making shared infrastructure participatory for citizens and making it visible and transparent so that people can also choose to participate at various levels.
Paths to shared infrastructure and Services
A few ways to share IT infrastructure and services to help solve the awful status quo are –
- Collaboratively or cooperatively built or maintained software.
- Investment in open-source components or applications
- Establish data standards
- Shared service APIs maintained by a parent government or consortium
- Internal APIs enabling agency and inter-agency systems
Three types of Government APIs
- Open APIs – APIs that are for the public. E.g., Real-time transit data API, Postal service address API.
- Trusted partners – These are APIs that a government or agency builds. To access these APIs, you must be a trusted partner and qualify for access. E.g., Medicare data project API called ‘Data at the point of care.’ The goal of this API was to connect healthcare systems with Medicare claims data of their populations in bulk so that if a doctor is working with new patients, they can immediately have access to all the patient’s details.
- Internal APIs – These are the most powerful APIs that we can have. Internal APIs enable a lot of data transfer within organizations that would otherwise be impossible or paper-based or require users to go to multiple agencies or teams within an agency to do anything. E.g., covidtests.gov
Driving forces for APIs in government
- Legislation – Now, you see APIs being legislated. You may have laws that mandate data to be open. Sometimes you have laws that mandate real-time access to information. You also have laws that fund interoperability and data exchange systems, which can manifest once they get to agencies as API projects.
- Internal demands – You use APIs for the modernization of legacy systems. You might have internal business needs to access data across an organization—some internal demands may be policy-oriented.
- Product innovation – Sometimes, it is industry inspired or trying to be competitive with the industry. Sometimes it’s filling market gaps.
To conclude, maybe we can have technology that is open source and federated. Maybe we could have a situation where we have some cooperatively purchased SAAS products so that cities can leverage their buying power to get better deals. Maybe we also have a federal or state-powered API with some open-source reference implementations or reusable visualization tools. Maybe we also have the use of some no-code and low-code solutions like base row, which is an open-source alternative to air table that is then able to connect with multiple internal APIs