Posted on 01-06-2014
I was asked to provides some thoughts on what is next for the US Government API strategy. I've been thinking about it during my work and travels over the last couple months, and I keep coming back to one thought: Strengthen What We Have!
I wish I had some new technology or platform for the next wave of government APIs that would ensure success with APIs in Washington, but in reality we need to do what we've been doing, but do it at scale, and get organized and collaborative about how we do it.
Release More Data Sets
There are thousands of data sets available via Data.gov, across 176 agencies and numerous categories. We need more. When any content or data is published via a government website, that data needs to also made available via agencies data repositories and Data.gov. Agencies need to understand that releasing open data sets it not something you do every once in a while to meet a mandate or deadline--it is something you do always, forever.
Refine Existing Data Sets
There is a lot of data available currently. However much of it is in various formats, inconsistent data models and isn't always immediately available for use in spreadsheets, applications, visualizations or analysis. There is a great deal of work to be done in cleaning, normalizing and refining of existing data, as well as deploying APIs around open data that would increase adoption and the chances it will be put to use.
Refine Existing APIs
Like open data, there are many existing APIs across the federal government, and these APis could use a lot of work to make them more usable by developers. With a little elbow grease, existing APIs could be standardized by generating common API definitions like Swagger, API blueprint and RAML, which would help quantify all APIs, but also generate interactive documentation, code samples and provide valuable discovery tools for helping understand where interfaces are and what they offer. The mission up until now for agencies is to deploy APIs, and while this remains true, the need to evolve and refine APIs will go a long way towards building those valuable case studies to get to the next level.
Robust /developer Areas
There are over 50 agencies who have successful launched a /developer area to support open data and API efforts. Much like open data and the APIs themselves, they represent a mishmash of approaches, and provide varied amounts of resources and necessary support materials. HowTo.gov already provides some great information on how to evolve an agencies developer area, we just need some serious attention spent on helping each agency make it so. It doesn't matter how valuable the open data or APIs are, if they are published without proper documentation, support and communication resources, they won't be successful. Robust developer areas are essential to federal agencies finding success in their API iniatives.
Every successful API initiative in the private sector from Amazon to Twilio has employed evangelists to spread the word and engage developers, helping them achieve success in putting API resources to use. Each federal agency needs their own evangelist, to help work with internal stakeholders, making sure open data is published regularly, new APIs are deployed and existing resources are kept operational and up to date. Evangelists should have counterparts at OSTP / OMB / GSA levels providing feedback and guidance, as well as regular engagement with evangelists in the private sector. Evangelism is the glue that will hold things together across agency, as well as provide the critical outreach to the private sector to increase adoption of government open data and APis.
Build Public / Private Sector Partnerships
Opening up data and APIs by the federal government is about sharing the load with the private sector and the public at large. Open data and APIs represents the resources the private sector will need to build applications, sites, fuel industry growth, and stimulate job creation. A new type of public / private sector partnerships need to be defined, allowing for companies and non-profit groups to access and use government services and resources in a self-service, scalable way. Companies should be able to build businesses around government Internet services, much like the ecosystem that has grown from the IRS e-File system, with applications like TurboTax that reaches millions of US citizens and allows corporations to help government share the load while also generating necessary revenue.
Establish The Meaningful Case Studies
When it comes to open data and APIs nothing gets people on board more than solid examples of successfel applications that have been build on open data, APIs. Open government proponents use weather data and GPS as solid examples of open data and technology impacting not just government, but also the private sector. We need to fold the IRS e-file ecosystem into this lineage, but also work towards establishing numerous other case studies we can showcase and tell stories about why open data and APIs are important--in ways that truly matter to everyone, not just tech folks.
Educate & Tell Stories Within Government
In order to take open data and APIs to the next level in government there needs to an organized and massive effort to educate people within government about the opportunities around open data and APis, as well as the pitfalls. Regular efforts to educate people within government about the technology, business and politics of APIs needs to be scaled, weaving in relevant stories and case studies as they emerge around open data and APIs. Without regular, consistent education efforts and sharing of success stories across agencies, open data and APIs will never become part of our federal government DNA.
Inspire & Tell Stories Outside Government
As within government, the stories around government open data and APIs needs to be told outside the Washington echo chamber, educating citizens and companies about the availability of open data and APIs, and inspire them to take action by sharing successful stories of other uses of open data and APIs in development of applications. The potential of using popular platforms like Amazon and Twitter spread through the word of mouth amongst developer and power user communities, the same path needs to be taken with government data and api resources.
The next 2-3 years of the API strategy for the US government will be about good ol fashioned hard work, collaboration and storytelling. We have blueprints for what agencies should be doing when it comes to opening up data, deploying APIs and enticing the private sector to innovate around government data, we just need to repeat and scale until we reach the next level.
How do we know when we've reached the next level? When the potential of open data and APIs is understand across all agencies, and the public instinctively knows that you can go to any government domain /developer, and find the resources they need, whether they are individual or a company looking to develop a business around government services.
The only way we will get here is by achieving a solid group of strong case studies showing that we are making change in government using open data and APIs. Think of the IRS e-file system, and how many citizens this ecosystem reaches, and the value generated through commercial partnerships with tax professionals. We need 10-25 of similar stories of how APIs impact people's lives, strengthened the economy and has made government more efficient, before we consider getting to the next level.
comments powered by Disqus
Winning in the API Economy
|Download as PDF|
Latest Blog Posts
- Swagger Visualization Layer Using D3.js
- Establishing Common Dictionaries That Industries Can Use In Their API Design
- Top 5 Most Popular Themes On API Evangelist In 2014
- Query Parameter Determining Which Fields Are Queried For API Call
- Now Our Development Environment Is Now Containerized And Scalable Like Our Production Environment
- Guest Post: Let Our Sponsors Blow A Little Smoke Up Your Ass
- API Discovery Continues Its Move Into The IDE With Eclipse Che
- Evolving Beyond Just Resources Towards A More Experience Based API Design
- Another View of The API vs. Data Download Model
- If You Have A Publicly Available Mobile App You Have a Public API