Adopting 3rd-party infrastructure, tooling, and services is an inevitable reality of API operations today. You will depend on 3rd-party infrastructure and services like GitHub, Postman, or Jira, and having a strategy for the history of why you have relationships with these vendors, and how you are using as part of your API operations, is a critical step towards getting a handle on the API sprawl and chaos that exists, wrestle with your legacy technical debt. Having a clear API vendor strategy goes hand in hand with establishing your API platform strategy, and goes beyond what is commonly associated with procurement efforts today. In 2024, if you don’t have a handle on all of the free and paid vendors your teams are using to produce APIs, it means that these vendors have a handle on your business that you do not control.
APIs are a great way to make digital resources and capabilities available outside the enterprise. They are also a great way to bore holes into the enterprise to extract value and get your software baked into someone else’s business. This is a core tenant of how you operate a startup. This is why bottom-up developer tool and platform infrastructure motions are so favored. Provide a free useful drill to developers within the enterprise and they’ll collectively begin to drill holes into the enterprise for you, and if you get enough of them doing this in the hundreds or thousands—you can drill some significant holes in the enterprise, and extract a lot of value over time. Standardizing procurement is one way to tackle this problem, but SaaS and API solutions have changed how technology gets applied across the enterprise, and is something that only some groups are starting to get a handle on with FinOps, and other approaches to developing a vendor strategy.
Without a vendor strategy for your API operations, and in support of well-defined API platform strategy helps connect the dots across all of the Infrastructure, tooling, and services your teams are using, but then also gets at why teams are using them in the first place. Ideally teams have a way of requesting the introduction of new Infrastructure, tooling, and services as part of platform operations, but shadow IT is still the most common way of implementing what you need to get the job done. Teams aren’t usually considering the big picture, they are just looking to get something they need done in their work. Having a clear API vendor strategy as part of your API platform strategy should give teams the agency and autonomy to adopt any 3rd-party or open source solution they want—with limitations and controls of course. But, teams should feel comfortable suggesting the addition of a new service or tool, and be provided with guidelines for evaluating and formalizing their usage over time.
The first rule of API club is the services and tooling you depend on to deliver your APIs, have APIs. This means that your vendors should always have an API that you can use in the automation of your platform. You should have API contracts in place for your vendors who are providing essential resources and capabilities. You should be able to get data in and out of these on-premise and cloud platforms, and seamlessly weave into your platform—otherwise you are just enriching their platform. Whether or not the Infrastructure, tooling, and services you are adopting have an API is the first red or green flag in your relationship. Teams who are just trying to get work done across the enterprise are not always thinking about this big picture and should be taught to look for an API, even if they aren’t automating right away. Whether or not your API vendors have an API themselves isn’t just a technical signal, it will shed light on their overall business strategy as well.
The second rule of API club is your services and tooling you depend on should be fluent with OpenAPI and JSON Schema, and allow for the input and output of API schema, and other artifacts. If the Infrastructure, tooling, and services you depend on allow for the input of OpenAPI, but not the output of OpenAPI, this is a deliberate move that illuminates what their overall business strategy is—teams should be taught to avoid these solutions. API specifications like OpenAPI are the life blood of the API economy, and as I’ve stated several times before, value accumulates on OpenAPI, JSON Schema, and other artifacts—this is why I am so focused on a spec-driven approach to API governance. You should use any vendor you choose as part of the operation of your API platform, but the ability to import and export OpenAPI and JSON Schema, or seamlessly weave them into your platform via APIs will contribute to the overall weakness or strength of your API platform going forward.
There is no right balance to build or buy within your enterprise, and as part of your API platform operations. How much you build or buy is up to you, and should be based upon your industry, and how you do business. However, all enterprise organizations should have a vendor strategy that goes beyond just procurement, looking at the value and adoption of specific digital resources and capabilities, whether a vendor has an API, and how the vendor has adopted open-source API specifications as part of their business strategy. An API vendor strategy is a layer of an enterprise’s overall API platform strategy, and should be woven into the automation of API operations via CI/CD pipelines and web hook integrations with source control. I will help enterprises establish a basic API vendor strategy, align with the overall API platform strategy, and then work to automate along a well defined API lifecycle using source control and CI/CD. I’ve learned along the way that this is the line of where I work with API governance, providing the artifacts and blueprints to help define, automate, and govern with automation on top of source control and CI/CD, but I am leaving the vendor relationships to each enterprise I work with, as this is where things wrong, or so very right depending on how well your contracts with your vendors are defined.
