There seem to be conflicting affinities when it comes to the best way to implement a software as a service delivery model. The common definition most people ascribe to this concept is a web-based software system delivered through a browser, just like web pages and web games do. This is, in fact, the best model in the opinions of most due to the compatibility that this guarantees as long as the browser is capable of sophisticated stuff.
But, there are many subtleties and different ways to implement a software as a service delivery model, and most have merits in certain situations above others, and these merits are very incidental most of the time. So, while I can’t say “this is the penultimate model”, I can at least take you on a brief tour of the more common models out there, so you can see why there are different models and how different ones tend to work well for specific scenarios.
#1 – The Cloud-Based Browser Model
This is the one I mentioned before, and it’s the one most people think of when they hear SaaS. This requires no installation by the company using it, using simple account logins once service is acquired, just like email, social networks or other remote service systems.
Being pure browser, and being offsite, it has the merits of needing no high level administration from your IT, and usually promises great hardware to run it at the location, without costing you what it takes to run this locally. But, it also limits customization and administrative privileges and takes a mild leap of faith when it comes to security.
#2 – The Local Browser Model
This differentiates from the cloud model because it is installed on a server belonging to the company using it. This server can be onsite, or a host server somewhere else. This puts the onus of all installation, configuration and administration entirely on the company’s IT people.
It has the advantage, though, of granting more freedom, customization, and less faith for security.
#3 – Non-Browser Model for Desktops
This is actually how practical SaaS began its life, and it’s still used for inventory systems, databasing and communication. This uses a compiled system as a terminal (or dynamic GUI), and a compiled system running on the server as well. This has the advantage of being a little harder to hack usually, but does not ensure the platform independence that browser models do.
#4 – Dynamic Mobile App and Browser App
This is more circumstantial than the others, and it’s a shortcut mostly to get around mobile web interfacing with standard web designs being a bit unavoidably awkward. While a better solution for this is to just include parallel mobile pages when going web-based, this is for the moment a popular default.
This basically is an XML-based mobile app that installs locally, but connects dynamically with web-based data and web computing technologies on the other end, but without complying to standard browser architecture.
SaaS designed this way is usually made into browser apps or extensions for compatibility with desktops (PC/Mac) as well. I discourage use of this model unless unavoidable honestly.
So, you see the four common types of software as a service delivery model, and given the different circumstances that make one or the other advantageous, you can see why there’s no consensus for now. Honestly, while I said I wouldn’t pick an “ultimate model”, the browser models are what’s probably going to win out in the long run … they mostly already have.
