I am deep into capablity thinking. I am having some interesting conversations which I will be publishing as podcasts, blog posts, and white paper shortly, but I need to keep hammering on some thoughts here before I am ready to hit publish on these stories. In my API Evangelist newsletter last week I was thinking about business alignment of capabilities, and this week I was thinking about alignment different public or private spheres that shape our businesses, which ultimately left me realizing that capabilities are about having an honest conversation about how much control we have or do not have with each integration we depend upon to do business today, and tomorrow. This is bigger than just API contracts, which is just about a single API–this is about business derivatives involving multiple API contracts.
Last week’s business alignment centered around my determination to align product and engineering in my work, but this week I began exploring the developer experience and customer dimensions of all of this productization, and found myself thinking about all the rich expertise that exists in an ecosystem, and specifically how that expertise accumulates around common standards. This exploration left me asking about how much of the control over your business integrations do you have? How much does your average engineer have, and how much does your average product person have? Or more importantly, how much does your average VP have?
I’ve long used the public, partner, and private phrasing to describe the APIs we produce and consume, but I find these words do not adequately describe the control we have over our APIs. I am looking to reconcile this with my definition of a capability. A capability describes all the technical bits of the APIs we are producing or consuming, but it also possesses all business bits of the services, data, and other elements of integrations. Just as important it describes all the human relationships surrounding these integrations—allowing us to begin having a conversation about how much control each stakeholder has or does not have.
You just do not see an honest conversation around control occurring around your usual API conversations–with producers or consumers. API contract testing and other approaches are looking to quantify this front line in technical terms, but your average API contract does not span multiple API providers, let alone include all the technical and non-technical stakeholders. I will do another pass over my current definitions of what a capability is and what capability thinking looks like, and find more ways I can better shine a light on and govern the control over access and the data we are making available via the endless number of integrations we are depending on to do business each day.
