In the first part of this series we talked about the different ways B2B commerce applications are being delivered today, the different application models available and the trade-offs associated with them. In the last two posts, we talked about SaaS and On-Premise applications and what factors drive businesses to choose that application delivery model over others.
In this post, we want to discuss a newly emerging application delivery model known as “API First Platforms” and examine some of the trade-offs of using it. In B2B commerce, API-First platforms are also referred to as cPaaS (Commerce Platform-as-a-Service), API’s or “Headless Platforms.” In all cases, the names describe a platform that is comprised of a combination of the back-end data model and business logic and a cloud-based infrastructure.
A defining aspect of cPaaS is that it decouples the User Interface from the back-end of the application.
This “decoupling” is accomplished by wrapping a REST API around the data model and business logic and allowing application access to the back-end via calling the API. The ultimate outcome is that the User Interface can be completely custom. In fact, the User Interface actually exists as a separate application that can have its own roadmap independent of other applications accessing the API. cPaaS offers developers the ability to begin development almost instantly without having to worry about setting up the underlying development environments or infrastructure. It also offers an array of tools, testing facilities, and application templates that can further speed the deployment of custom user experiences. For these reasons, cPaaS platforms offer the best of both SaaS and on-premise models without many of the negatives.
- Customized functionality: Because cPaaS user experiences are independent applications they can be completely custom. Applications can also start from “templated” applications offered by the cPaaS provider or by the community of developers around the cPaaS.
- Roadmap control: As independent applications, the user experiences built around cPaaS platforms are owned by the organizations who build them. Those organizations have complete control over the feature roadmaps in their applications.
- Developer Communities: cPaaS ecosystems can be similar to open-source in that there is a community of developers that provide features or extensions back to the cPaaS that others can use.
- Speed of Implementation: The goal of cPaaS is to provide rapid custom application delivery. By providing all the underlying application elements, infrastructure and templated user experiences, cPaaS is able to achieve remarkably quick implementation times.
- Bundled infrastructure: Since the infrastructure is bundled, it is optimized to perform and scale. It is also managed by the cPaaS provider, so there is no need to have those resources on staff.
- Lower upfront costs: Relative to code or “on-premise” applications, cPaaS typically has lower upfront costs since you don’t have to buy software licenses and hardware to get started.
- Customizations require developers, but with modern cPaaS platforms, most development can be accomplished by less experienced resources that know how to work with web sites or web applications.
Based on the points above, more and more businesses will choose cPaaS as an application delivery model because it offers a modern approach combining the benefits of on-premise applications with the benefits of SaaS.
Companies that desire custom functionality and roadmap control will gravitate to cPaas over SaaS. In addition, lower upfront costs and speedy implementation times will drive organizations to cPaaS over on-premise applications.