--- layout: post title: The API Lifecycle (My Talk From @Defrag and @APIStrat) image: https://s3.amazonaws.com/kinlane-productions2/talks/november-2015/Beck_Map_1933.jpg author: name: kinlane tags: - Lifecycle - APIStrat --- I recently told the story of how I view the API life-cycle, based upon my research across the space, at the [Defrag Conference in Broomfield, CO](http://defragcon.com/), and at my [API Strategy & Practice conference in Austin, TX](http://austin2015.apistrat.com/). I spent two weeks pushing my research forward in preparation for these talks, and wanted to take a moment to gather my thoughts, and share the narrative of my talk. When I first gave this title and abstract for both the Defrag and APIStrat keynotes, I called it "the 17 stops along a modern API lifecycle". After pushing my research forward, to support these talks, it became 26 stops, then those became what I am calling "lines", resulting in me just call the talk "the API life-cycle". I use my public speaking as a vehicle for my API research, helping me polish my work, and ultimately pushing me to craft better narratives around my work, but most importantly, make it more coherent, and make sense to the average individual. One way that I do this, is to root my stories in history, build upon the earlier work in the tech space, and anchor them to other relevant areas of our everyday lives. Everything I do as the API Evangelist is built on the hard work of men and women who came before me. From the 1940s... ![](https://s3.amazonaws.com/kinlane-productions2/talks/november-2015/compute-1940s.jpg) The 1950s... ![](https://s3.amazonaws.com/kinlane-productions2/talks/november-2015/compute-1950s.jpg) The 1960s... ![](https://s3.amazonaws.com/kinlane-productions2/talks/november-2015/compute-1960s.jpg) The 1970s... ![](https://s3.amazonaws.com/kinlane-productions2/talks/november-2015/compute-1970s.jpg) The 1980s... ![](https://s3.amazonaws.com/kinlane-productions2/talks/november-2015/compute-1980s.jpg) The 1990s... ![](https://s3.amazonaws.com/kinlane-productions2/talks/november-2015/compute-1990s.png) The 2000s... ![](https://s3.amazonaws.com/kinlane-productions2/talks/november-2015/compute-2000s.jpeg) Getting us to the current decade, where I saw the potential of delivering the compute resources we needed for the mobile devices, that were quickly becoming ubiquitous in our daily personal as well as business lives. Designing, deploying, and managing APIs in support of mobile was the catalyst for my research as the API Evangelist in the summer of 2010. ![](https://s3.amazonaws.com/kinlane-productions2/talks/november-2015/compute-2010s.png) As the API Evangelist, all that I do is map out what I am seeing across the API space, mapping out what API pioneers like Amazon and Salesforce are doing, as well as how recent API darlings like Twilio, SendGrid are executing on their API operations. I take this awareness, and map it against the services that leading API service providers are offering, in hopes of establishing a more coherent view of the overall API space.  I conduct my research in hopes of helping API providers better understand how to establish a more successful strategy, but with a focus on being able to articulate this not just internally, but with developers, partners, and potentially the public at large. APIs are important. They are increasingly the pipes that are driving our personal, and professional worlds, and it is important that we do them as well as possible, so that they benefit everyone involved. In 2015, I feel like I am the [Henry Beck of the API space](https://en.wikipedia.org/wiki/Harry_Beck). If you aren't familiar with his work, he was one of the original minds behind a different way of thinking about mapping, designed for public transportation, that is still used today to describe major transit operations in cities around the globe. ![](https://s3.amazonaws.com/kinlane-productions2/talks/november-2015/henry-beck.jpg) In 1933, Henry Beck created a map of the London Underground, that was decoupled from earlier ways of mapping and communicating around transit resources, in a way that was focused on how the resources would be experienced by end-users, evolving beyond a focus on the transit resources themselves, and their location in our physical world. [![](https://s3.amazonaws.com/kinlane-productions2/talks/november-2015/Beck_Map_1933.jpg)](http://homepage.ntlworld.com/clivebillson/tube/tube.html) Earlier approaches to mapping out the subway reflected traditional mapping techniques, and were bound to legacy physical elements like roads, rivers, mountains, and buildings. While maps like this one from 1889, were technically accurate, they didn't always convey an increasingly complex subway system to end-users as they experienced it. ![](https://s3.amazonaws.com/kinlane-productions2/talks/november-2015/1889small.jpg) Even into the new century, subway maps were plotted along roads and rivers, leaving them coupled to legacy elements, and ways of thought,  ignoring the fact that end-users of the subway were not thinking in these terms as they put the transit system to use. Riders just wanted to know how they needed to get where they were going, and not be burdened with these legacy elements they often do not even see. ![](https://s3.amazonaws.com/kinlane-productions2/talks/november-2015/1902small.jpg) By 1915, public transit engineers like Henry Beck were rethinking how they mapped the transit infrastructure, in a way that helped them better communicate their increasingly complex infrastructure internally, but most importantly, in a way that helped them communicate externally to the public. In 2015, this is what I feel like I am doing. Mapping out all the stops along the increasingly complex API life-cycle, in a way that helps API providers better understand their own life-cycle, but also like the subway map infrastructure, in a way that helps them communicate to consumers, and end-users. ![](https://s3.amazonaws.com/kinlane-productions2/talks/november-2015/api-lifecycle-tag-cloud.png) At this point in my research, I am asking myself how  I take the 26+ common areas of an API life-cycle and create standardized lines, that I could possibly be communicated in a common way, using the subway map analogy. As I approach the end of 2015, I have 809 building blocks, in 149 categories, across these 26 common areas--I need a more universal approach to plotting these out, and the subway map is providing me with one possible way of doing this.