All This Information Is Great, But Where Do I Start With My API Strategy?

I shared a list of just the essential building blocks from across only 21 areas of my API areas of the API life cycle with a company I'm helping craft an API strategy for, and I got some very common feedback--all this information is great, but where do I start with my API strategy? This is excellent feedback, as that particular overview is void of any specific 101, or on-boarding elements for each of the areas of the API life cycle that I cover. 

This is on purpose for this particular document, providing me with a generic outline that I can use in many different scenarios, but the feedback rings loud in my ears, and is something I get constantly. I receive a constant barrage of emails, tweets, and voice mails asking me where they should get started with their API strategy, spanning both the provider, and consumer side of the API coin. 

The problem for me in all of this is that what "API" means, where someone is at in their journey, and what their overall goals are, can be radically different depending on who you talk to. What API design means to you, may not be what it means to the next. What API deployment might be about gateway solutions in your organizations, for others it means cloud based, or possibly specifically with a Java API framework like Restlet. My goal in my research is to to map out each area, distill down the common building blocks, then yes, build as many introductions (101), and on-boarding doorways as I can, targeting both API provider and consumers, across a wide variety of business sectors, and the public sphere.

To help illustrate my point, I get regular requests from folks around how do they pull all the data on Twitter via the API, and how do publish a video to all the leading video platforms via APIs. In the same day I will get requests on where do you start in defining a rating system that applies to all APIs, or start with APIs at a large higher educational institution where you have no contacts, with a very hostile IT department. The scope is wide, and varies dramatically, so creating a single document providing everyone with a getting started point is very, very difficult.

With that said, it is what I am working towards. 2015 was very much about mapping the scope of the entire space, and organize into specific areas (right or wrong). 2016 is very much about making sense of those areas, and each stop along the API life cycle, within the areas that I have mapped. I'm working on 101 pages for all 50 of the life cycle areas you find on my home page at the moment. I am already working with my partner 3Scale to take all the common building blocks I have, organize them into different areas, to craft what I'm calling "playbooks" for different verticals. 

If you are looking to deploy a content or data API, there will be a playbook. If you are looking to get started with APIs at your existing institution, government, or enterprise organizations, there will be a playbook for you. I plan on taking the overall map of the API life cycle I've drawn, and the common building blocks I've identified within these areas, and begin remixing and publishing them as specific scenarios, providing "playbooks" that hope to be relevant to more specific situations, helping organizations and individuals better understand where they should be starting with their API strategy.