Important SaaS Architecture Considerations for Legal Tech Software

by Kunjan Zaveri

With nearly all eDiscovery software now being offered on a SaaS basis, the cloud architecture decisions supporting the vendor’s platform are pivotal. Decisions on architecture design can lead to either very successful or very poor outcomes. The right architecture depends on the company’s SaaS delivery strategy, their customer profile and size, and the volume and nature of their anticipated transactions. These considerations are especially important in the legal tech space, which has some unique requirements and market dynamics such as heighted security and customization for large clients, and channel support (requiring platform portability), which are generally not as relevant to general SaaS architecture considerations.

At a high level, it is important to understand the two main SaaS architectures: multi-tenancy and single-tenancy. In cloud computing, tenancy refers to the allocation of computing resources in a cloud environment. In SaaS, tenancy is categorized into two formats: single-tenant SaaS and multi-tenant SaaS. In the single-tenant SaaS environment, each client has a dedicated infrastructure. Single-tenant products can’t be shared between clients and the buyer can customize the software according to their requirements. Multi-tenancy is an architecture where a single instance of a software application serves multiple customers. In a multi-tenant SaaS environment, many organizations share the same software and usually the same database (or at least a portion of a common database) to save and store data.

Single-tenancy and multi-tenancy SaaS each have their advantages and disadvantages, and the selection of either approach by a legal tech SaaS vendor should depend on their overall product and go-to-market strategy. Here are some of the advantages of a single-tenancy architecture:

1. Improved Security

With single-tenancy, each customer’s data is completely isolated from other customers with fewer and more trusted points of entry. The result is better overall security from outside threats and the prevention of one customer accessing another’s sensitive information, either intentionally or inadvertently.

2. Reliable Operations and Individual Tenant Scalability

Single-tenant SaaS architectures are considered more reliable as there is not a single point of failure that can affect all customers. For example, if one client uploads a massive amount of corrupt data that taxes resources and crashes the system, it won’t affect another clients’ instances. Single-tenancy is actually more scalable within an individual client instance, while multi-tenancy can better scale the addition and management of many customers.

3. Customization

Many large customers need specific features or unique security measures that require custom development, which can be very difficult in a multi-tenancy environment. Companies that use single-tenancy architecture can upgrade their services individually. Rather than waiting for the software provider to launch a universal update, users can update their accounts as soon as the download is available or decline patches that are not needed by a specific customer.  

4. Portability

With single-tenancy, a vendor can host their platform in their own SaaS environment, a channel partner’s environment, or enable their customers to install the solution behind their firewall or in their private cloud. Multi-tenancy SaaS does not allow for this flexibility.

Multi-tenant SaaS Advantages

Multi-tenancy is commonly utilized as most SaaS offerings are consumer or otherwise high-volume commoditized offerings, which necessitates such an architecture. Here are some of the key advantages of multi-tenant SaaS architecture over single-tenant:

1. Lower Costs

Since computing services are all shared under a multi-tenant architecture, it can cost less than a single-tenant structure. Scaling across the customer base is easier as new users utilize the same uniform software and resources as all the other customers.

2. Efficient Resources Spread Across all Customers

Because all resources are shared and uniform, multi-tenant architecture uses resources that, once engineered, offer optimum efficiency. Since it’s a changing environment where resources are accessed simultaneously, multi-tenant SaaS software needs to be engineered to have the capacity for powering multiple customers at once.

3. Fewer Maintenance Costs

Maintenance costs are usually associated with a SaaS subscription and aren’t passed through to the customer or incurred by the channel partner like with a single-tenant structure.

4. Shared Data Centers

Unlike a single-tenant environment, a vendor doesn’t have to create a new instance within the datacenter for every new user. Customers have to use a common infrastructure that removes the need to continually add partitioned instances for each new tenant.

So which architecture is the right one for a legal tech SaaS vendor? It completely depends on the company’s strategy, pricing, and nature of the offering. To illustrate this point, consider the examples of two hypothetical legal tech SaaS vendors: Acme and Widget.

Acme provides do it yourself data processing on a high-volume, low-cost basis, handling about 700 matters a week at an average project value of $400. Acme’s customer base is primarily small to medium size law firms and service providers who have multiple projects on different cases over the course of a year. Acme’s clients do not want to fuss with hardware or any software maintenance requirements.

Widget offers an enterprise-grade compliance and security data analytics platform, sold at an average sale price (ASP) of $400,000, but as high as $2 million for a dedicated annual license. Widget has 32 active enterprise customers and hopes to grow to 70 customers in three years with an even higher ASP. About a third of Widget’s clients prefer that Widget host the solution in Widget’s cloud instance. Another group of clients are large financial institutions that, for security and governance purposes, insist on self-hosting the platform in their own private cloud. The rest are instances sold through channel partners who prefer to host the platform themselves and provide value added services. Many Widget customers have particularized compliance requirements and other unique circumstances that require customization to support their needs.

For Acme, the correct choice is multi-tenancy. Acme offers a commoditized SaaS service, and it needs a high volume of individual customers to drive more transactional revenue growth. A single-tenancy architecture would prevent the company from scaling, would be too expensive, and unmanageable. However, some legal tech companies who have opted for this architectural approach have made the mistake of pursuing a more low-market commoditized strategy without making the initial considerable investment in engineering expertise and resources to build such an architecture.

In contrast, single-tenancy is the optimal architecture choice for Widget. While single-tenancy cloud is slightly more challenging to support, Widgets’ premium enterprise offering requires portability for the channel and rigorous security minded clients as well as customization, and thus is a clear fit for single-tenancy. In the future, Widget may have closer to a thousand customers or be acquired by a much larger company that will want to deploy the solution to their extensive client base. It would be a good idea for Widget to architect their single-tenancy platform in a manner, such as employing microservices, that will allow it to readily port it to a multi-tenancy environment when warranted.

So, for legal tech executives, the question to ask is whether your strategy and product offering is more in line with Widget or Acme. But the bottom line is to make sure your strategy drives your choice of architecture and not the other way around.

Kunjan Zaveri is the Chief Technology Officer of X1. (www.x1.com)

Leave a comment

Filed under Best Practices, Cloud Data, eDiscovery, Enterprise eDiscovery, SaaS

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s