The API Journey: We Do Not Always Get Our API Strategy 100% Perfect, But We Can Communicate, Learn and Evolve

Running the perfect API operation is pretty much a delusional dream. Even leaders  like Twilio and AWS have platform, and ecosystem produced problems on a regular basis. In my opinion, API are all about the journey, and we may never get our strategy 100% perfect, we can communicate, and evolve along the way—this is what I consider the API journey.

To help demonstrate this in action, here a post from the GSA, about the SAM API, on the US Government API Forum:

We've, rightfully, heard complaints about the SAM API languishing and the documentation not being as functional as it needs to be. We want to make sure users of the API feel comfortable using it to build real applications off of. We've adjusted how we're staffing the API as well as raised the priority the API in the eyes of our developers.

To you, this means this: 

1) At a minimum, we're sweeping through new GitHub issues weekly, but we will do everything to go through those issues more rapidly.
2) We're going to increase our transparency by making sure that anything in our backlog that's API-related is in a GitHub issue - if it's prioritized with a date, that'll be made clear, too. We want to make sure you know what's coming and on what days - and the docs will be updated to reflect what's currently implemented and what's coming.
3) We're going to publish our version management plan to the SAM API site so it's more clear what's going to cause a version change. One of the things about the SAM data is that regulations may change our data, so we should be treating some of it (like reps and certs) as variable-length instead of fixed to keep systems from breaking, so we absolutely document that.

We've already added some updates that include reference data that wasn't available before and a few minor cleanups. Expect the more as we ramp up our people at this to be worked through by the end of next week. We appreciate being held to task on this - IAE's larger strategy relies on usable, exciting APIs and we can't do that if we aren't serving you.

This is why I prescribe APIs, not because APIs are a technological wonder that magically fixes everything (they do, oh they do). I prescribe APis because of the API journey, and if done right, the API provider can change, evolve, and learn to better serve their consumers, and in this case constituents.

APIs are born out of breaking down legacy walls built up between IT and business operations, but they have also become about breaking down walls built up between inside the firewall, and outside the firewall. In the end I do not think APIs are the thing that will change government or companies, it is the process of doing them, learning to open up and communicate, that will move the needle forward.

Something that will not happen at your agency, organization, institution, or business if you do not start on the API journey yourself.