High Velocity Object Models for SaaS

This post discusses Data object models for SaaS and how small subtleties can lead to big gains. We will consider an online document collaboration SaaS company with a three tier architecture. The lower layer of the architecture is composed of XML data web services, and as the name suggests - is responsible all data access and storage.

There is also a more business savvy app services layer (labelled biz logic in the diagram below) with objects which speak more directly to business processes. The app services layer persists and operates on these objects through the data web services layer.

Data Web Services Layer
This is a Restful XML web service layer. Resources are accessible through simple CRUD methods (same as the HTTP verbs: POST, GET, PUT, DELETE). Each resource is fully backed with a well defined and versioned XSD document. In addition, every method is fully defined a XML schema.

The resources in this layer are geared to be generic and abstract in nature. These objects are reusable across multiple application services. As a result, a lot of thought goes into creating a new abstraction. These abstractions are designed to last for a long time - many times longer than an organizations product offering.

Lets list out common abstractions as examples:

• User: A person who uses SaaS offerings
• Account: A virtual entity that purchases products, governs and manages multiple Users
• Notification Channel: Email, SMS, APNS, Twitter etc.
• Request: A User making a request in the System
• Message: A Message can be constructed based on Person, Transaction and Notification Channel
• Product SKU: A purchasable unit of value added product offering such as storage, request type transactions etc.
• Payments: Users making payments for Product SKUs to be provisioned on their accounts
• Content: blobs of information that are residing on a hard disk drive. These can be copied, deleted, transferred as one unit. This unit is versioned over its lifetime.
• Set: an unordered set of one or more files that can participate in single or multiple  Requests
• Tree: an ordered tree of files that can participate in single or multiple Requests

App Services Layer
This is also a Restful JSON/ XML service layer. JSON bindings provide the velocity for coding rapidly against these services. Each resource is fully backed with a well defined and versioned XSD document. In addition, every method is fully defined a XML schema.

The vernacular of object names is tied to the current product definition. The operations on app services objects span multiple data web services. The concerns to solve in this layer are extensibility, flexibility, and high velocity. The shared vernacular between product and engineering teams help in easy consumption of engineering deliverables and discussion of new features.

The resources defined in this layer are more immediate in nature and consumed directly by applications. For example, lets study a typical Send Workflow Object.

1. COLLABORATOR.POST(): create a new User if necessary
2. SEND.POST(): create a Send Request object with recipient Users and Message
3. FOLDER.POST(): create an arbitrary Tree of files
4. FILE.POST(): create and upload a Content unit
5. FOLDER.PUT(): update the folder Tree
6. SEND.PUT():  the Send Request is put in a sealed state, ready for delivery
7. EMAIL.POST(): generate and send Email Notifications about the Send Request

Now, lets study a similar Share Workflow Object.

1. COLLABORATOR.POST(): create a new User if necessary
2. SHARE.POST(): create a Share Request object with recipient Users and Message
3. BATCH.POST(): create an arbitrary Set of files
4. FILE.POST(): create and upload a Content unit
5. BATCH.PUT(): update the Batch with this new Content
6. SHARE.PUT():  the Share Request is put in a ready state
7. EMAIL.POST(): generate and send Email Notifications about the Share Request

Summary

In the case of my employer, we started and grew the company with mainly the Send workflow since 2006. In 2010 we noticed increased market demand for Share workflow - we were able to quickly turnaround (6-9 months, in 2011) and put in new Share, Sync & Sign product offerings in the market through the use of our reusable data web services.

Please note that in the App Services example above, I have turned around typical offering of our Send (Batch of files)/ Share (Folder of files) offerings to illustrate the simplicity of reusable data web services.