I spoke on a panel at the Red Hat, Fed Scoop Government Symposium in Washington D.C. yesterday. I had some great conversations with technology vendors, as well as government agencies about everything API. I enjoy being outside the Silicon Valley echo chamber when it comes to technology because I enjoy helping folks understand the basics of what is going on with the basics of APIs, over getting too excited over the latest wave of new technology, and a constant need to be moving forward before ever getting a handle on the problems on the table.
It can be hard to to repeat some of the same stories I’ve been telling for the last seven years while in these circles, but honestly the process helps me refine what I’m saying, and continue to actively think through the sustained relevancy of the stories I’ve been telling. After this round of discussions in D.C. I feel there are a some themes in my work, I can keep refining, and crafting stories for sharing in the government space.
- Open - I know its a tired term, but learning to be more open with other agencies, partners, and the public is an essential component of doing APIs in the federal government.
- Documentation - Do not reinvent the wheel with documentation, and leverage OpenAPI to help you keep documentation usable, up to date, and valuable to developers using existing open source API documentation solution.
- Support - Provide email, office hours, Twitter, ticketing, Github issues, and other common support building blocks for API consumers, making sure people know they can get help when they need.
- Communication - Talk to your consumers. Have a blog, Twitter account, and other social channels for communicating internally, with partners, and publicly with API consumers.
- Experiment - See your APIs as an R&D extension of an agency, and allow for experimentation with APIs, as well as the consumption of the APIs. Think about sandboxes, data virtualization, and other ways of minimizing agency risk.
- Education - Make sure you are reaching out, educating, and providing training for all API stakeholders, ensuring that everyone is up to speed, and making no assumptions about what people know, or do not know.
None of this is technical. This is all basic API knowledge that any business or technical API stakeholder can take ownership of. These are all things that I see kill API efforts in the public, as well as private sector. These are all things that IT and developer folks scoff at and feel are unnecessary, and business users do not always see as an essential part of technical implementations. These are all deficient elements present across the 100 developer portals, and the 500 APIs I keep an eye on across the federal government. They are common building blocks of API operations that I’ll keep beating a drum about on my blog, and in person at events I attend in D.C.
The API environment in D.C. would frustrate your average API developer, architect, and evangelist. I get frustrated at the speed of things, and having to say the same things over and over. However, I also understand the scope of what the federal government does, and the number of people we have to get up to speed on things. The number of APIs available is actively growing, but the consistency, usability, and effectiveness of APIs isn’t keeping pace. To keep things in balance we are going to need even more evangelism around operating government in an online environment, and how APIs can help provide access to data, content, and even algorithms across all branches of government in a safe and secure ways.
