Shifting Gears Between the Technology and Politics of APIs
26 Jan 2018
I’ve been working on two talks for API Days in Paris next week. These talks are at two opposite ends of the API spectrum for me. The first one, API Is Not Just REST, is rooted in the technology of APIs, but then touches lightly on the business and politics of APIs. The second one, a regulatory subway map for PSD2, is all about the politics of APIs, but then touches lightly on the business and technology of APIs. I have the outlines for both talks done, and I’m working on the narrative and slides for each, along the way I’m really caught by how different each end of the spectrum are, and require me to use a different part of my brain–something I think really defines the yin and yang of APIs.
When I’m down at the protocol level of APIs, thinking about the details of HTTP, TCP, and the nuance of how headers are used, and the messages we pass back and forth, the politics of APIs do not matter to me. My developer and architect brain is absorbed with the technical details, and the human or political consequences of my decisions really do not matter all that much. As long as things are technically correct, and my responses and requests are doing what is expected, I am good. It is easy for me to be railroaded within this technical silo, and I wouldn’t ever need to be concerned for the business and politics of it all, if my work as API Evangelist didn’t force me out of my comfort zone.
Inversely, when I’m thinking about the politics of how this all works, and the intention and impact of regulatory guidance like PSD2 in Europe, the technical details of HTTP, headers, and what messages I’m using feel less important. Sure, they still matter to what I’m trying to do, but the strictness in which I define my protocols, headers, data formats, schema, and other gears of API operations takes a looser form. When you look at banks who have NO PUBLIC API, just getting them up an running seems much more important than ensuring each HTTP response status code is present, and each schema is perfectly represented. Eventually, I will need to make sure all my technical i’s are dotted, and t’s are crossed, but I have bigger battles to wage at the moment.
As I’m pulled back and forth between the technical and the politics of APIs, I find myself becoming very, very aware of the business of APIs, and how the complexity of both technology and the politics are wielded for business gain. Seeing how technology is used as a competitive advantage, as well as leveraging politics to get ahead in the game. You see this in the rhetoric around PSD2, where invoking the bogey man can be very telling of a company’s position, just as much as the company’s who are proactively jumping on the PSD2 bandwagon, and getting ahead of the game, or even being a leader when it comes to defining implementations. Competitive edges can be sharpened by embracing political shifts, as well as through the adoption of leading edge technologies present across the API space (Kafka, OpenAPI, etc.)–it really depends on your organizations approach to the API game, and how up to speed you are on how it is played.
While I don’t feel it should be everyone’s role to be exposed to the all the extremes of the API sector, I do feel like we do a poor job of exposing developers and architects to the business and politics of it all in a meaningful way. I also feel like we spend too much time either hiding from or protecting business users from the technical details. I find that I learn a lot being pulled back and forth to either end of the spectrum, something I’m hoping to share as part of my talks next week in France, as well as the conversations I have in the hallways at the conference, and meeting rooms before and after the event. I look forward to seeing you all in Paris, and Grenoble next week.