When building an application on the Software as a Service (SaaS) model, there are a number of technical considerations to be looked at to ensure that it meets the customers’ expectations and your business needs. Here are five of them.

1: Multi-tenancy

Your application absolutely must support multi-tenancy, and it needs to do so in a way that is seamless to developers to work with. In the past, I have tried doing things where I put a tenant identifier on every table, and while it worked, it was frustrating — I needed to check everywhere to ensure the user belonged to the same tenant as the data. One moment of forgetfulness, and I would cause a security risk where someone could view (or worse, edit) data belonging to another tenant. One reason I swung so hard in the direction of OutSystems Agile Platform is because it has built-in tenant management and data management, which took so much of this pain away. Other systems may work in a similar fashion, and I highly recommend that you seek them out rather than trying to build your own (speaking as someone who has built their own).

2: Zero-downtime architecture

With internal systems, you can get away with downtime in many cases. There will be grumbling and anguish, but if the boss says “deal with it” users have no choice. On a SaaS model, customers count on annual downtime being measured in minutes at most, not hours (let alone days). It is tempting to think that the responsibility for downtime rests on the system and networking teams. But the fact is, developers contribute to downtime too. The big difference is that the downtime we cause is typically planned for, so we do not view it as downtime. With SaaS, users do not distinguish between the two.

Here are common situations that SaaS applications need to handle without interruption in service:

  • Servers being down (database or application)
  • Third-party services being down (the application should only lose this portion of functionality, not be totally broken)
  • Upgrades and patches
  • Debugging/troubleshooting
  • Server restoration (bare metal, files-only, and VM snapshots)
  • Backups

The bear of the bunch there is upgrading. You need a system in which you can deploy new versions without more than a speed bump to users. The days of “the system will be down from 10 PM to 2 AM on Sunday” do not exist for most SaaS applications.

3: Whether to commit to a vendor

When you are looking at a SaaS model, you need to be able to rapidly and easily scale your application, and that most likely means working with a cloud vendor. The easiest choice up-front is to have your application run in a VM just like it is any other application. This gives you a ton of freedom and flexibility with your vendors. If they offer a VM with the OS and other services (like a database) that you need, you can use them. It is trivial to mix and match vendors to provide failover or options in case you are not happy. The downside is, scaling is not always trivial, and in many cases you are now looking at some systems administration work.

The alternative is various cloud frameworks such as Microsoft’s Windows Azure. These systems rock because they can automatically scale and give redundancy, geographical dispersion, etc. The downside is you are now tied very deeply to a vendor or a framework. Some of these systems (again, Azure comes to mind) can be deployed locally or by any cloud vendor who wants to offer them, which at least gives you a selection of vendors. But if you discover that the choice was not a good one, you are now in a “live with it until you can rewrite your application” scenario, which is not fun.

Along the same lines, there may be technologies that will make your life easier as a developer, but you will need to carefully consider if they have enough vendor support to provide you with the choices you need to support a SaaS application.

4: Technical alignment with business model

When your application is run in-house or sold to a customer for them to install, there is not much you need to worry about in terms of how the technology supports the business model, other than game developers who seem to worry about DRM a lot. But for SaaS applications, the business model can create constraints for your technical design. The biggest issue is resource usage. If your resource usage does not scale at the same rate (or preferably a lower rate) than the revenue, or scales on a different variable, you have a big problem. Another consideration is that you need to support the billing model. If you are billing on some sort of metered rate, then your application needs to be able to accurately report the basis for that metering.

5: Scaling

Can your application scale? Out of the box, many applications cannot scale well. They are not designed to handle scenarios like multiple users accessing the same pieces of data, load balanced servers, etc. Well-designed SaaS applications will need to have a strong layer between the data and the application so the data backend can scale separately from the business logic and presentation layers. They will also need to be able to provide their business logic via APIs so that mobile applications (and other non-Web clients) can be built, as well as enable integrations with partners’ and customers’ systems. Again, these are all things that are typically not addressed with “shrink wrapped” software, but for SaaS they are virtually mandatory.


Additional SaaS resources

For more on this topic, check out the ZDNet and TechRepublic special feature Cloud: How to do SaaS right and our downloadable Executive’s Guide to Best Practices in SaaS and the Cloud.

Keep your engineering skills up to date by signing up for TechRepublic’s free Software Engineer newsletter, delivered each Tuesday.