Multi-tenant versus Single-tenant ERP

All enterprise pundits are predicting that cloud ERP and Multi-tenant architecture is the future. With limited funding and available technological options the multi-tenant architecture may become a norm of future. For ERP and to be specific Oracle ERP going from single-tenant to multi-tenant does not make sense unless the business is:-

1.      Expanding to new geographies which constraints robust services support after implementation.

2.      M&A with organizations which have a completely different structure and way of working.

Before any comments on single-tenant or multi-tenant, let’s start by trying to define multi-tenant ERP. Though if you look at Wikipedia it sums it up nicely by saying “the principle of multi-tenancy is not universally accepted and supported within the software industry.”

Under a strict definition, a multi-tenant application is a single piece of software that is shared by multiple users. But, there are many components which can be “multi-tenant” – these include the application code, operating system, data storage software, and computing resources. In an ERP application there are many varieties of multi-tenant depending on which of these resources are shared.

Even within the data storage, there are many different options. The ideas of separate databases, shared database – separate schema, and shared database – shared schema. There are articles discusses the trade-offs involving development time, economic savings, backups, scalability, security and regulatory concerns. Scope of this blog is at strategy level so not provided in details.

Different multi-tenant architectures are better suited to different types of ERP customers. Complete multi-tenant is best suited to small companies or specific vertical solutions which have highly repeatable and mostly standard processes. Multi-tenant options with single-tenant components are best suited to larger businesses with non-standard processes or significant integration requirements.

In the future, if there are well followed cloud ERP standards and a wealth of applications, the distinction between these models tends to erode. As all clouds interact seamlessly and more applications are available, the need for integration will become less and less. Though still waiting to hear something reliable on this/.

Ideal uses for multi-tenant

Multi-tenant applications, operating systems, data storage, and computing resources are tools that can be used to perform work. In the case of ERP, the work involves running a business with proper automation, accounting, and reporting. A good craftsman has many tools in his bag. Multi-tenancy is one of those tools. Just like a carpenter would not use a chain saw to cut molding, software engineers will not need to use multi-tenant applications in every ERP situation.

Multi-tenant is appropriate for business tasks that are common across many customers or divisions of a company.

ERP customers need the following:

·      Features that meet business needs

·      Security and regulatory compliance

·      Ability to modify application if business needs change

·      Lowest possible price for all considerations above

The last point is perhaps the most important because both single and multi-tenant applications can be used to solve most problems, but with comparable features, price and security will be the deciding factors. The security issue is beyond the scope of this posting, but we may get to it in a future article.

Multi-tenant pricing

Multi-tenant ERP systems are generally priced competitively with their legacy system counterparts. This means that multi-tenant vendors are pocketing additional profits, not reaching critical mass, or not realizing the cost savings that have been promised.

Multi-tenant systems can gain economies of scale with regard to:

·      Shared hardware costs (most talked about, least important)

·      Shared IT resources (Most important in era of high resource cost)

·      Application and OS upgrades

The most talked about is the infrastructure savings, but the most important is the cost of IT resources and software updates. For many mid-sized ERP implementations the cost of hardware can be only 5% of the overall project cost – meaning that an additional 20% hardware efficiency will only save customers 1% of their overall project cost.

The savings from reducing IT staff by eliminating software installations and upgrades is far more compelling, but only on a case-by-case basis.

Multi-tenant systems can be potentially more expensive because:

·      Feature development – custom features have to be developed by specialized resources

·      Additional application need to compensate gap in features

·      Vendor lock-in

·      Potential expensive integration

Vendor lock-in can come in many forms such as limited support options, price increases, forced upgrades, and lack of customization features. Sometimes these issues can lead to higher out of pocket expenses and sometimes they lead to higher costs in terms of limited business processes.

Typical issues with multi-tenant environments are which are forcing and will continue to be an issue for organizational adoption (till resolved or addressed)

Issue	Organizational Impact
Integration issues with other internal applications	High
Feature gaps/ Painful customization	High
Security concerns	High
Total Cost of ownership/Pricing Models	High
Performance	Medium
Lack of choice	Medium

Ideal multi-tenant applications

From a customer perspective, the ideal multi-tenant application is one where hardware costs are high relative to the application cost and where the application is a commodity to eliminate the opportunity for vendor lock-in.

Utility applications such as email and web-hosting fit these requirements and are well suited to a multi-tenant design. Implementing and maintaining email and web servers can be expensive, and sharing this cost across multiple customers will reduce costs tremendously. However, even simple applications like email and web hosting may require some customization. For example, different customers may want different firewall settings for their web server or different spam filters for email.

ERP applications have lagged behind others in terms of multi-tenant adoption. Small businesses with simple processes or enterprise departments have started taking advantage of this trend, but in many cases, ERP applications are highly customized programs with interfaces into multiple systems. While Salesforce.com attracted a part of CRM market given similar sales practices across industry domains but entire multi-tenant ERP market is fraction of total market. This could be because the costs associated with customization tend to outweigh the benefits of multi-tenant, or because the larger businesses lag behind when it comes to adoption of new technologies.

Customer size matters – Multi-tenancy in larger businesses

When a customer is large enough to support a full time IT staff and uses enough resources to justify several servers, the benefits of multi-tenant become quite small. A business of this size can benefit from economies of scale without a shared multi-tenant architecture. The customer can install the application in-house or outsource the work depending on security considerations and business requirements.

However, businesses with multiple offices may still benefit from multi-tenant architectures through cost reductions associated application upgrades across different operating entities.

Multi-tenant ERP in the enterprise

Businesses running multi-tenant applications only have to update one application, while those running multiple copies of a single tenant version will have to do multiple upgrades. The same principle applies to the operating system. One operating system is easier to patch than multiple operating systems.

For example, a web-based architecture may allow a company to serve all divisions and entities using a single copy of the application. In the case of ERP, this means that the application needs to be able to manage multiple currencies, different business processes, and maintain separate reports for the different operating entities. In this scenario, the definition of multi-tenant is stretched to mean different operating units instead of different companies. By running multiple operating units on a single application, the enterprise can centralize operations and save costs.

Multi-customer versus multi-entity

Multi-tenant ERP versus multi-entity ERP

Vendors offering a multi-customer architecture (multiple non-related entities on one ERP application) will not be able to provide the same flexibility as a multi-entity architecture (multiple subsidiaries or other related entities). Advances in software are making it possible to customize more through configuration, but a multi-customer architecture will always be limited with regard to building external interfaces, modifying data structures, and building custom processes.

Small businesses with standard processes can use configuration tools, metadata options, and database schemas to customize a multi-customer architecture to their needs. Medium and large sized businesses with complex processes and multiple integration points would be best served by their own multi-tenant software license.

Recommendation - Managing your multi-tenant ERP architecture

I think you will be a biot dissapointed by my recommendation as my recommendation is :-

• It depends.....

Every organization , customer, entity is different and there is no silver bullet which can address all organization issues in a single architecture or option. The organization can be either

1.   Option 1: Outsource everything (hardware, licensing, upgrades, and configuration) to a single vendor who rents the software to you and manages all operations.

2.   Option 2: Outsource hardware, licencing, upgrades. Keep configuration in house or with trusted partners.

This distinction is over-simplified because these options can be packaged many different ways, but this abstraction is useful for the discussion that follows.

The best option for your business depends on your cash flow requirements, operational expense versus capital expense, company IT resources, and your company culture. Companies wanting to preserve short term cash should utilize option 1 while companies who want to own their systems and depreciate them over time should utilize option 2. Companies with spare hardware and IT resources should purchase while companies with little IT expertise should select the rental option 1. For larger ERP customers, option 2 is usually the most cost effective over an extended period of time.