Archive for the ‘SaaS’ Category

SaaS Design Checklist

gears2I’ve been asked several times recently about the design considerations for an application that is to be delivered via the Software-as-a-Service (SaaS) model.  In other words, beyond the core functionality of the application itself, what other features or system aspects need to be addressed for the business offering of that application as a commercial service?

The following is a list of such features or aspects.  I make no claim as to the all-inclusiveness of this list, but it’s a good start.  Certain system aspects that apply broadly whether the application is SaaS or just critical-internal have been omitted (e.g., disaster recovery, health monitoring, etc.).  As for items listed, they may or may not apply to every situation, but they should at least be considered serious before deciding.


  • Subscriber-Level Authentication & Authorization:  A “subscriber” is the entity with whom the business relationship exists for use of the SaaS application and comprises one or more users.  Each request must be authenticated to know the subscriber to which the user belongs thereby enabling license checks and usage metering.  Subscriber authorization comes into play if the application has separately licensable modules to which their users may or may not have access.
  • User-Level Authentication & Authorization:  As in all applications, each request must be authenticated to know the originating user and authorized to access specific capabilities by their role.  This authorization may be further constrained by subscriber-level authorization constraints.
  • Parametric Throttling:  A request may contain parameters that if unchecked could harm the system intentionally or otherwise.  For example, consider a request argument that dictates the number of records to return.  The application may protect itself from crippling values like 1,000,000,000 by simply throttling it to some configurable maximum like 500.  Throttling rules may need to be subscriber-specific.
  • Frequency Throttling:  Also important generally but particularly for APIs is the notion of throttling request rates (i.e., maximum hits per second from the same IP address) to prevent anything from abusively heavy subscribers to denial of service attacks.  This is often achieved within the network infrastructure as opposed to the application itself, but this is an opportunity for making the point that a successful SaaS deployment is about more than just the software engineering.

Service Level Agreements

  • Availability Monitoring:  SaaS contracts often carry SLAs that specify minimum application uptime.  When this is the case, a means for self-monitoring availability must be established whether to tout your success, to be the first to know about issues, or simply to address disputes.  Be specific about the very many ways to define uptime.
  • Performance Monitoring:  SLAs may also specify performance thresholds and require similar monitoring for similar reasons.  Individual performance data points should include the subscriber ID and request type to enable rollups in these dimensions since a) different subscribers may demand different SLAs, and b) different request types may have inherently different performance characteristics that can be called out separately with different thresholds.
  • Performance Exclusions:  Depending on the nature of the application or specific requests, there may be portions of execution time that should be excluded from performance calculations.  For example, the implementation of a request may call out to external services or execute a subscriber-specific workflow (i.e., things beyond the SaaS provider’s control).  Such activities may have been excluded from the performance SLAs and thus must be captured enabling the appropriate adjustments.
  • Compliance Auditing:  Collecting all supporting data is necessary, but not sufficient.  Reporting on this data for the purpose of auditing specific SLAs must be established and should be exercised internally to avoid surprises.

Subscription Servicing

  • Request Metering:  Requests incident on the application should be counted by subscriber ID and request type.  This enables usage monitoring by subscriber which may be required to support billing depending on the business relationship.  It also enables internal sensing of more heavily used features; information that can be useful in several ways (e.g., tuning, marketing, deprecation).
  • Subscriber-Level Reporting:  Separate from whatever reporting the application itself provides, there should be a means to generate summary information about a subscriber’s SaaS interaction whether periodically or on-demand.  This information may include usage levels, SLA compliance, license status, strange account activity if detectable, etc.  Minimally, the SaaS provider should be able to retrieve such information, but may also consider making it available to subscribers perhaps as an admin role capability.

External Services

  • Performance Monitoring:  Many applications integrate with externally provided services to perform portions of their request functionality (e.g., information retrieval, payment processing, etc.).  As the consumer of these services, the SaaS application should monitor their performance.  Whether or not the time spent waiting for these services to execute is included in formal SLAs, they will absolute impact user experience.  Downward trends may lead you to shop around for equivalent alternatives.
  • Availability Monitoring:  For all the same reasons, apparent availability of any external services should be tracked.  Apparent availability is the percentage of calls to a service that the service responded in a functionally meaningful way.

Resource Sharing

  • Multi-Tenancy:  A single infrastructure or slice thereof serving multiple subscribers is central to the SaaS economic model.  The most crucial aspect of this is the notion of a multi-tenant database schema.  The problems associated with isolating subscriber data logically rather than physically are easily offset by the maintenance benefits of dramatically reducing the number of production database instances.
  • Partitioning:  Economically, a single multi-tenant database may be ideal.  At scale, however, it may become necessary to have multiple databases each supporting a subset of subscribers.  This may be done to support different SLAs, to service very different usage patterns, to reduce the impact scope of an outage, or simply to handle high scale loads.
  • Selective Purging:  Even the best SaaS applications will lose subscribers.  Purging their data from a multi-tenant database is usually straightforward, but not so when it comes to backup media of multi-tenant databases.  If you’re entering into a contract that originates from the subscriber’s legal department, read the termination clause carefully and be sure it’s feasible.
  • Subscriber Portability:  If subscribers are partitioned across multiple databases, the need to move a subscriber from one instance to another will eventually arise as usage patterns change (the SaaS analog to rebalancing your 401k).  The biggest hurdle to this is avoiding ID collisions across databases.  The catch-22 is that this is rarely considered in release 1.0 and the downstream fix usually requires prohibitively invasive surgery.
  • Cross Partition Monitoring:  Partitioning subscribers across multiple databases or even whole infrastructure slices obviously adds to operational complexity.  As the number of partitions grows, consider some form of central monitoring hub to assist the Operations support staff.  This can start out simple and evolve over time as the ROI increases, but good sensors within the application can greatly facilitate this when the time comes.

Flexibility & Extensibility

  • UI Customization:  User interface flexibility can range from take-it-as-is to full white labeling per subscriber.  It can be as trivial as showing the subscriber’s logo or hacking up every form and navigation to comply with some internal process guidelines.  Ultimately the market will decide what level of customization capabilities are worth the engineering for a given application.
  • Data Model Customization:  Similarly, subscribers may have additional data fields, whole data objects, or even multimedia content that they wish to store along with the application’s data model.  Again, this type of flexibility has many prices and the value in supporting it needs to be assessed case by case.
  • Behavioral Customization:  A more complex type of flexibility is that of business behavior (e.g., configurable workflows, proprietary decisioning rules, calculation policies, etc.).  Unless tightly and explicitly bounded, this type of flexibility in a multi-tenant SaaS deployment can be an insidious slippery slope.  Tread carefully.
  • Platform API:  Many applications perform services that can be exposed via an API (e.g., web services).  Doing so can enable subscribers to incorporate the application more deeply using, for example, a Service Oriented Architecture (SOA) while increasing subscriber stickiness for the SaaS provider.  It also opens up the potential for multiple UIs, which may be a path to extreme UI customizations.  However, while exposing such APIs may appear straightforward, it is definitely not to be undertaken lightly.  More on this in another post.