In a traditional model, this means that the requirement/design/build process for the API will delay the dependent application team's development efforts, as everything is part of this linear, serial process. But by taking a different approach, utilizing APIs can actually speed development instead of creating yet another dependency-driven impediment.
This new approach is built on the concept of Service Virtualization, which is a way to create a virtual endpoint to simulate an API that doesn't exist yet. Application developers can consume this endpoint, which looks and feels like the real API to the consuming application. Scenarios can quickly be added to simulate different API behaviors, and all before a single line of API code is written. This has some obvious, and not so obvious, benefits.
Decrease development time. By virtualizing the endpoint up front, API development and consuming application development can happen at the same time. The application developers don't have to wait for the actual API to be developed, compressing project timelines and getting to market faster.
Decrease development cost. In the traditional model discussed above, the API development team has moved onto another project by the time the application team is developing against the completed API. As problems or gaps are identified, it's a costly proposition to get the API development team spun up on an additional 'enhancement' project post-release. Alternatively, in this new model, the API is being developed while the application team is developing against the virtual endpoint, so design and behavioral issues are uncovered while its much less costly for the API development to fix them.
Remove back-end system dependencies. When an API is built on expensive legacy and core systems, these can be difficult to maintain multiple test environments for. These systems, in their test environments, can also be rather volatile. Having that drive the uptime of your test API is not ideal. By virtualizing the API, all back-end system dependencies are removed.
Allow separation of SDLC's. Consuming application developers will need both a test and production version of an API to facilitate their own development processes. Much like the test API should not be dependent on back-end systems (as discussed above), consuming application developers don't like being dependent on a test API that is not reliable. Likewise, API developers need flexibility in their own development processes and don't need their test environments bound by external consumers. This challenge is not one that shows up early in an API Program's lifetime, but it is absolutely pervasive and often appears only after it becomes a difficult thing to implement due to the size of the program. The solution is quite simple. Use Service Virtualization to create a 'production sandbox' which is a virtual representation of all production endpoints. API consumers use this sandbox for testing & development, providing a stable environment for them and freeing the API development teams up to manage their test environments at will.