There are fewer topics I’ve discussed more than the concept of the API lifecycle. I’ve worked for years to try and standardize how I tell stories about the API lifecycle, and have worked with number API service providers when it comes to standardizing their offerings to help define each stage of the enterprise API lifecycle. The API lifecycle will mean different things depending on who you talk to in the enterprise, which is one of the reasons you must nail down a common working definition of what the lifecycle is and isn’t as part of API governance. I do not care what stages you consider to be the life cycle, and opinions will vary about what happens within each stage of the life cycle, but if you are going to be successful with API governance across the API lifecycle, you will have to do this work.
OpenAPI has done wonders for aligning teams producing APIs about the surface area of an API, and I am determined to do that with APIs.json and other API Common schema describing the API lifecycle and properties of those APIs. I have several API lifecycle schemas that I’ve worked hard to hammer out with enterprise customers over the years, and I will take all of that work and craft into an API Commons definition that I can reuse across my own APIs, but also my customers. I consider an API lifecycle schema to be a common strategy level artifact that can be reused across many individual APIs within a domain. I have plenty of opinions on what the API lifecycle can be, but all I can do is advise folks to map out a life cycle that is closest to what they have today, and iterate upon it once it is defined and socialized. I personally do not care what stages there are in the life cycle, as long as they are defined, and someone does the hard work to socialize it and organize policies and rules sensibly all along the stages of the life cycle.
An API lifecycle artifact is just a set of policies organized by stages of a lifecycle. Whatever you call it, develop & deploy, design & develop, or something more sophisticated, the important piece is you have some commonly agreed upon names for the stages and have negotiated the policies and rules that need to be satisfied to consider a stage of the API lifecycle complete. The stages of a life cycle may vary from team to team or they could be agreed upon across the enterprise, with the policies shifting from domain to domain and team to team, with some policies being universal. The ultimate goal of a human and machine-readable API lifecycle with agreed upon names of stages, and an ever evolving base of policies isn’t to automate everything 100%, it is to make sure all API stakeholders, both business and engineering are in agreement about what the API lifecycle, and what policies have to be satisfied at each stage of an APIs evolution. The schema for the API lifecycle becomes the agreed upon factory floor for any API being developed across any area of the enterprise, producing consistent and repeatable APIs.
I feel pretty strongly that the lack of an agreed upon API lifecycle is the greatest cause of API sprawl and chaos, and will be the leading cause that API governance efforts don’t succeed. Without an agreed upon set of stages to move an API forward from definition to distribution, everyone involved will just be talking past each other, or not talking at all. I leave it to the enterprise to define their own API lifecycle, and ideally coordinate with teams on this lifecycle definition. Where I come in is helping standardize that lifecycle, and help organize policies for each stage, organizing machine-readable Spectral rules which can be automated, and help review each API when the time is right. I’ll let teams decide what stages there are, and which stage policies should come into play, but also when and where rules and other types of automation can or can’t occur. Ultimately, it isn’t my API factory floor, I am just the guy who comes in and helps define the blueprint for the factory floor, help wire it up across different domains, and make sure each API being delivered is done so via the API factory floor. I will also help gather questions and feedback along the way to help make adjustments to the factory floor in the future to better optimize for the needs of different types of APIs.
Governed enterprise APIs require a strongly typed API lifecycle. Everyone needs to be speaking the same language and have the same expectations, and new stakeholders to the party need a way to quickly get up to speed about what is involved with delivering an API from definition to distribution. An API lifecycle schema has all the policies associated with each stage, as well as the Just-in-Time API Guidance associated with each policy and rules applied across each stage. First and foremost the API lifecycle is about introducing and guiding teams throughout the API lifecycle, and secondarily about automating and enforcing the rules associated with the policies at each stage of the life cycle. Without it, teams will never quite know where they are in the life cycle, talk past each other about what is expected during the delivery of APIs—resulting in the sprawl and chaos that is all too common with enterprise operations today. I will be sharing the API lifecycle for the APis.io API search engine, and demonstrating how it gets applied to the public search API, and the others I use to automate the search engine. Then I will be offering it as a service to my enterprise customers, adding to the strategy, program platform, policy, and rules services, providing another dimension to organize API governance.
