Is there a “Right” Application Architecture for SaaS?

If you want a SaaS application that is scalable, highly available and extensible there are a variety of best practices you should consider. Following best practices does not require using a specific programming language. You can build scalable SaaS applications in Java, .Net and even PHP.

The key is to start with layering the application into logical and physical layers. When you layer the application carefully consider how you physically separate layers. You’ll also want to make sure the layers are loosely coupled to ease future physical separation to facilitate scaling up.

Typical layers included in a SaaS application:

• Presentation Layer (a.k.a. the UI)
• The Business Logic Layer
• The Application Framework Layer
• The Object Relational Mapping (ORM) Layer
• The Web Service API Layer
• The Caching/Persistence layer
• The Database layer

Out of the gate you should be considering an off the shelf Object Relational Mapping (ORM) layer to plug into your application. ORM offers several benefits. First and foremost, with ORM you standardize the data access code and speed application development. With and ORM layer you can even switch database vendors if required. Before buying a commercial ORM tool, carefully evaluate open source ORM layers such as Hibernate, Nhibernate or iBatis.

Within the individual layers of the application beware of unnecessary chattiness between the layers. Also be aware of making it too easy to load an unnecessarily large object graphs. Meaning only get the data when and where you need it.

If you are selling to the B2B space you will need to make integration with 3rd party applications fast and easy. Building an API using web services with SOAP or REST are the tool of choice for providing a Service Orientation for SaaS application. Keep in mind; you will need to throttle user access to API to prevent performance degradation. Typical throttles include restricting the volume of data that can be retrieved over a specific period of time and restricting the number of connections.

During the design phase try to break a single logical app into services when there’s a clear need for integrations, or when the need to span and cluster hardware is foreseen in a functional area. For long running operations try to leverage asynchronous operations. For example, consider building a request pipeline at the application layer. When all requests (retrieve, save, delete, etc) funnel through common code, you have a unified injection point for security, logging, performance monitoring.