Recently, my colleagues in the Postman Open Technologies Program and I were discussing API lifecycles. It quickly became apparent that we each had our own mental models for what was (and *most certainly was not *) worthy of inclusion.
A quick survey of search results hints that the industry has as many opinions about what constitutes an API lifecycle as we had:
- TechTarget has a five-step lifecycle: plan, dev, test, deploy, retire
- Apigee promotes an 8-step version: design, develop, secure, publish, scale, monitor, analyze, monetize
- Axway lists three steps (with many, many substeps): creation, control, consumption
- SmartBear mentions 5, but a different five than TechTarget: planning and designing, developing, testing, deploying, retiring
- Mulesoft mentions 4: design, implementation, security, management
- Redhat features a confusing conjoined set of circles, and 13(!) kitchen-sink steps: strategy, design, mock, test, implement, deploy, secure, manage, discover, develop, consume, monitor, monetize
The process that evolved during my time as Capital One’s Center of Excellence Director skewed heavily to the needs of a large, mature, and internal system. As a result, our API lifecycle:
- Made no mention of monetization
- Emphasized discrete team ownership and end-of-life elements
- Hand-waved past development requires as code creation had its process, controls, and oversite group
The process that resonated for us, eventually, was:
- Discover: Has someone already solved this problem?
- Define: Who will own the work at a team and LOB level, what access models will be in place, what SLAs need to be met, etc.
- Design: Engage with stakeholders, make an OpenAPI representation, get feedback, iterate
- Develop: Code the thing (subject to many, many other criteria outside the API group)
- Deploy
- Deprecate: Plan for ending or superseding with a subsequent version; includes communication plan, timeline expectations, etc.
- Delete Define what info sticks around for historical purposes while ensuring any executables, access tokens, and gateway routing is removed
So why all the variation? Why isn’t there a “right” or “correct” API lifecycle?
I think the variation is largely because lifecycles are created within companies to generate particular outcomes. Nobody installs a lifecycle for the sake of having more to train and enforce. If sloppy design leads to losses in a competitive marketplace, a company should have an explicit “design” step in its lifecycle to drive better outcomes. If security has been a mish-mash, a dedicated “security” step should be elevated as part of a lifecycle process to prompt more focus on correcting that behavior.
A monitoring company is sure to list monitoring as part of its lifecycle. A company that sells documentation software will also elevate documentation to a high-level concern. It will depend on the vendor, but whatever their product excels at will probably be part of whatever lifecycle they promote.
With companies looking at instituting a lifecycle, I’d first find the burning problem that would benefit from additional learning, creativity, and focus. That would be the first touchstone called out in the path between an idea’s inception and production runtime. I’d then continue to build up and out from there. Dropping an entire thirteen-step lifecycle where none previously existed isn’t just introducing a massive amount of disruption all at once - it also summons a proportional amount of resistance.
