API is a pretty catch all acronym for what is happening across the enterprise these days. I haven’t been writing enough here on the blog to help me separate the layers of the API onion as I work each day, so I wanted to take a crack at doing some storytelling around the different types of APIs I am seeing enterprise organizations work with. An API can be any type of programmatic interface, including language, hardware, or the more web-based, but the biggest defining characteristic of APIs in my experience are how they power business operations, and where in the supply chain they exist. Ultimately, the impact that APIs have on business is very much defined where they live within business operations, and how they work together overall to move a business forward—-here are the dimensions I am thinking about at the moment.
- Operations ~ This is one area that I find folks have trouble seeing APIs, and realizing that our APIs have APIs. Realizing that Github, Amazon, Jenkins, Kubernetes, and our other pieces of critical infrastructure have APIs isn’t a stretch for many, but applying them to API operations always seems like just out of reach for most teams cognitive load. In my mind, this is where true API governance will come from, and if we are looking to automate more of the API factory floor this is where we should be looking.
- Microservices ~ Developing simple, do one thing well services are here to stay, even with the complexity they introduce. Enterprise organizations are working to decompose their monolith into many individual services that utilize a variety of different patterns as part of overall operations. Making discovery, traceability, and observability a critical part of operations, as well as having an honest approach to mapping out, understanding, and minimizing dependencies across operations.
- Partner ~ Even before many enterprise organizations publish any API publicly, they are exposing digital services to their partners, laying the foundation for public API operations, but centered on making valuable resources available to trusted partners. Partner APIs are where enterprise organizations get their feet wet when it comes to exposing internal resources to the outside world, but are doing so in a way that has a more direct line to revenue and value creation.
- Public ~ While much of the growth in APIs over the last five years has been in the microservices and partner realm, public APIs are still increasing as a way of doing business on the web. From my position there really isn’t much different between partner and public APIs, but there is an important distinction here when it comes to helping organizations make the proper investment in their API Operations, and while not all may feel they aren’t ready for public APIs, they can take what they’ve learned with partners and keep growing their investment.
- 3rd Party ~ I feel like this one is the most obvious, but has become a surprising area of growth and adoption for many organizations I am working with. Most do not have a plan for how they select, adopt, integrate, manage, and work with 3rd party API providers. It is something that has just grown organically and organizations are beginning to struggle with the challenges of using tens or hundreds of different 3rd party APIs across their operations, demonstrating the role that APIs are playing in the next wave of enterprise growth.
For me, there isn’t much difference between operational and 3rd party APIs, as well as partner and public APIs, but the nuance I find is important when it comes to getting organizations to think more strategically when it comes to their API operations. Another thing that defines the APIs that exist in these different buckets are maturity, and whether or not they are ready for primetime usage, or something that needs more baking before served up outside a firewall. Really, my reasoning behind writing this post was to just get all of these dimensions on the same page so I can think more about helping enterprise organizations begin developing a holistic strategy that addresses all of these areas, but also begin thinking more deeply of automation across the lifecycle that involves all of these areas of API development.
I feel like organizations who are further along in their API journey are getting a handle on microservices, partner, and even APIs in the public sphere. However, I see only a handful of folks who I see intelligently putting operational APIs to work to automate their API operations, or approaching 3rd party API consumption with any formal strategy. These two areas feel like the next front in optimization, observability, and taking cranking up the velocity across API operations. You can’t develop and sustain all the APIs you will need to make your business run, and you will never optimize and increase productivity on the API factory floor without being able to automate and orchestrate across the entire API lifecycle. Those are earlier on in their journey are still working to get more organized around how they are doing microservices, as well as partner and public APIs. Where those who are further along in their journey are continuing to get a handle on these areas, but are also realizing the importance of the APIs of the infrastructure providers they use, as well as the other 3rd party APIs that makes business move forward.
