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 post, we talked about SaaS and what factors drive businesses to choose that application delivery model over others.
In this post, we want to discuss “code” as an application delivery model and examine some of the trade-offs of using it.
Code can be referred to here as an open-source code base or an on-premise application.
In either case, “code” is a combination of the the front-end user interface and the back-end data model and business logic. Code requires the user to provide the underlying infrastructure (web and database servers, storage, network components, etc.) and policies. When traditional “on-premise” code bases are installed with an external infrastructure service (like Amazon Web Services, or RackSpace) they are referred to as “virtualized” applications. This is different than SaaS in that SaaS companies have a single code base that all customers use simultaneously. This is called “multi-tenancy”. In addition, SaaS companies manage, operate and optimize the infrastructure to deliver their applications as part of the service. On-premise code is “single-tenant”, meaning that the licensee is the only company accessing that code base and is responsible for managing and optimizing the underlying infrastructure, no matter where it is located.
- Customized functionality: Because “on-premise” applications are “single tenant” the individual instance of code is used by a single organization. Therefore, that code can be modified for functionality, either by the developers of the software, or in the case of open-source code, by anyone. These modifications can be specific to the instance because it does not have to be shared.
- Roadmap control: In the case of open-source code bases, independent developers can download and make changes to the underlying code, giving some control to the organization regarding feature development.
- Developer Communities: Also in the case of open-source code bases, there is a community of developers that provide features or extensions back to the code base that others can use.
- Separate infrastructure: Since the infrastructure is not provided by the software company, the user is responsible for managing the infrastructure that the code resides on – servers, connectivity, database, backup and disaster recovery, etc. In addition, application performance is impacted by infrastructure, so IT resources need to be skilled in interfacing the application and tuning it for performance on the infrastructure.
- Higher upfront costs: Relative to SaaS applications, on-premise applications generally have higher upfront costs due to licensing models and infrastructure costs.
- Development resources: Customizations require developers that know the code base and how to make functional changes to it.
- Speed of Implementation: Implementations require code to be deployed and infrastructure to be readied. Customizations will add further time before applications can go live.
Based on the points above, businesses choose on-premise or “single tenant” applications when they require vast amounts of customization in addition to the generally available features of an application. They typically have the technology resources on staff to further develop the code they are using and have in-house expertise in tuning the software and infrastructure to perform properly. These companies are willing to trade ease of use and implementation speed for total ownership, roadmap control and customization.
In the next post, we’ll take a look at the pros and cons of a newly emerging delivery model for business applications called “API-first” platforms.