The API Lifecycle (My Talk From @Defrag and @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, and at my API Strategy & Practice conference in Austin, TX. 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...
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.
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. 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.
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.
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.
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.
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.
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.
|Terms of Service|
The problem I am facing, is how do I properly map out these lines, in a way that reflect the role the play in an overall life-cycle? This is the difficult place I find myself currently, but will be working to solve using the subway map tools I am developing. They beauty of this analogy, is that I will be able to create multiple iterations over time, as well as be able to fork, and evolve maps for different platforms--similar to how multiple cities use the same subway map for their cities unique infrastructure.
Even once I find a rhyme and rhythm to mapping out the lines, stops, stations, and flows for my version of the API life-cycle, how will I do the same for the actual APIs themselves? I will need each API to follow a version of the API lifecycle, but also potentially possess its own, entirely separate journey, unique to a single API or potentially a stack of APIs.
Eventually I envision a world where I don't just have my entire API life-cycle mapped out, as well the journey involved with each of my APIs, and the API collections I define, I want a real-time visualization for my entire infrastructure. I want to see where each API is on the API life-cycle, as well as see where each of my API consumers, and even API users are on their own journey.
This might seem like a pretty tall order, but when you take a closer look at things, you realize that over 75% of the elements present in my API life-cycle definition, also has an API. My API management with 3Scale has an API, and my API monitoring with API Science has an API. I'm increasingly choosing API service providers that have an API, because I need them to be a real-time contributor to my overall API lifecycle.
With my API infrastructure being API driven, I can now think of my API life-cycle subway map in API terms. I can dynamically plot out each API I operate as a journey, depicted as its own subway line, and also make sure each API interacts with its respective API life-cycle journey--all using APIs. *mind blown*
But wait there is more! It gets even better--it just so happens that I also have an API for the subway map. It is just an alpha version, but using this API, I can dynamically plot out the map of each area of my API life-cycle, as well as for each individual API, and its own journey on the life-cycle.
I'm not sure where all of this API life-cycle mapping will go. I'm hoping it will help me think through the API life-cycle, in the context of my overall API industry research, as well as my own APIs that I operate. I am hoping the process will help me decouple the way I approach my APIs from some of my legacy ways of thinking, built up over the last 25+ years a software architect.
I am hoping I will start to see my APIs in a new light, breaking away from thinking about them in a linear way, through the lens of the applications I build on top of them, as well as the resources they are developed from. I want my APIs to be decoupled from much of their legacy constraints, and reflect more how they will be consumed by developers, and experienced by end-users.
I am not under any illusions that this process will be easy, and it will probably take a great deal of time, and iterations, much like it did for early subway architects, when it came to mapping out early transit infrastructure.
Until finally, I'm hoping I will find a way to describe my own API life-cycle, and APIs, in a universal way, that could work for other API providers, and even API service providers. It took over 15 years of iterating on early London Underground maps, before they finally landed on this design in 1933.
Beck developed an approach to mapping transit infrastructure that would also work for defining complex transit infrastructure over almost a century later. The approach he helped define, is still applied as part of how we map out, as well as communicate transit infrastructure, around the globe in 2015. I hope I can apply some of the same principles to begin defining the virtual API infrastructure we are increasingly depending on in 2015.
While Ian Bogost was tweeting in jest about using a subway map for all written and visual communications, the tweet was very timely and relevant for me. It came across my Twitter timeline, just as I was crafting my subway map keynotes for Defrag and APIStrat. While I do not favor the subway approach for "all written and visual communications", I do think it has potential for "discursive synthesis" of the potentially complex API infrastructure that we are building in 2015.
Through my work, I am hoping to establish a sort of subway map line "toolbox" for communicating around the API life-cycle that I have spent the last five years defining. I am looking for this toolbox to give me a way of communicating and collaborating with others in a way that reflects common API industry approaches, while also being able to customize for specific platform needs.
In addition to having a toolbox that reflects a modern API life-cycle, I am hoping the subway map approach gives me a set of tools I can use to visual the life-cycle of every individual API within my control. I desperately need a common way visualize my APIs, as well better understand where they exist within my overall API life-cycle.
Having a common way to describe and communicate around transit infrastructure is critical to society operating, and the global economy. I feel pretty strongly that having a common way to describe and communicate around the API infrastructure we are increasingly depending on is just as critical critical to society operating, and the global (API) economy.
We need an approach that reflects how companies around the globe are already operating their APIs, acknowledging the value of existing successful patterns of interoperability, established by the Amazons and Twitters of the world, but also allows for the flexibility, customizablity, and unique needs of individual companies, and industries.
The standardization, as well as uniqueness of what I'm talking about can be seen in the beautiful array of subway maps for major cities around the globe. These amazing maps meet the transit needs of each cities, while also embracing the principles laid out by early transit planners like Beck.
My storytelling at events like Defrag and APIStrat, as well as on my blog, always reflects where I am at with my research. Next I will be crafting more meaningful version of subway maps for each area of the API life-cycle, as well as an overall view showing all 809 building blocks, in 149 categories, across the 26 areas I track on as part of my research.
I am anticipating that I will hit some areas where the subway map analogy fails me. I am already thinking about some ways of augmenting API specific elements on the approach, to help me better communicate specifically about API infrastructure. An example of where I'm bending this, is the concept that an individual API can have its own map, and line, as well as be a passenger on other lines--I just need to come up with a sort of wormhole station connector element that helps communicate this relationship and / or transition.