While in the early stages of a large Microsoft Dynamics CRM deployment for a nationwide non-profit organization, our team of Dynamics CRM consultants were asked to clarify deployment options to help the organization make more informed decisions. One of their inquiries being the advantages of adopting a multi-tenant deployment. An interesting subject, and after a great deal of thought I realized for an end-user organization there are far more potential issues than there are advantages.

What is Multi-Tenancy?

To start the discussion let’s clarify what it means to deploy an application within an organization using a multi-tenant architecture.

Multi-tenancy involves a single instance of a software application which serves multiple customers, also known as tenants. In this case customers could be different areas of business, geographic regions etc. In such a scenario, each tenant’s data is isolated, inaccessible and non-existent to other tenants. If Dynamics CRM was the application in question, each business unit or tenant would have its own set of records stored in their environment, invisible to other tenants.

Is it a Good Idea?

While it is possible to multi-tenant the deployment of Microsoft Dynamics CRM within a single organization, the additional complexity is profoundly problematic.

• There is a need for a separate database/CRM instance to house the “golden record”
• There is an increased complication with respect to synchronizing data across environments. The updating of records in one environment when a corresponding record in another environment changes is no longer automatic, nor is there a way to even identify possible matching records across environments.
• There is a need for a separate CRM instance to house services required in common across the multiple tenants, with the extra coding, QA and maintenance required to integrate such common services to the separate tenants.
• The same staff may require multiple User Accounts, one for each instance, especially if they are transferred. This creates potential hazards with respect to synchronization with Outlook, e.g., correspondence and contacts from one CRM environment being inadvertently created in another CRM environment.

The short term ease of just setting up a new instance is more than offset by the long term pain of trying to integrate the systems down the road. After all, the point of going with Dynamics CRM is to provide a complete vision of an organization’s relationship with any given contact by having a common platform for such relationships. Erecting artificial barriers strikes me as counter-productive.

Advantages of a Single Tenant

• One set of common business rules to be maintained, e.g., the name change process in one environment applies to all three (unless business rules dictate otherwise)
• Synchronization efforts are limited to out-of-the-box data duplication functionality
• One set of users with no duplication
• All correspondence with Contact centralized

In practical terms, our client could proceed with allowing duplicate records owned by different business units as if they existed in separate databases should they go with a single tenant architecture. This would keep synchronization of changes to such records tightly controlled.

We realized quickly that the utilization of the Business Unit hierarchy in the out-of-the-box CRM should be quite sufficient to reflect the true nature of our client’s data. The Security Role configuration will be sufficient to dictate which user can view records beyond their Business Unit. Field Level Security can ensure that key fields within a viewable record are only available to Users whose Security Role or Team Membership permit access. The native Business Unit/Security Role/Team/Field Level Security model is quite sophisticated and capable of straightforward configuration without resorting to multi-tenant environments.

Consider the situation in our non-profit customer’s environment. Imagine a community member requested services from the non-profit organization, but was also a financial donor, these are two different types of contacts under two different units of business. If that same person was affected by a disaster and applies for emergency relief from the organization this would create an entirely new, third type of contact. This individual can either be represented by a single contact record (that provides full oversight to the appropriate staff) OR by multiple contact records owned by three distinct business units. These three contact records could be linked by a custom entity (let’s call it a Contact Match). A change of address for one such contact record could spark a similar change, either automatically or after appropriate approval, for the other two contact records.

After all that you may be thinking, why should I care about multi-tenancy at all? The choice appears to be a concern solely for vendors like Navantis which may operate separate and distinct instances for clients, as we do with Peopleworks. However multi-tenancy matters just as much to buyers, or at least it should. While a single tenant is more appropriate for an end-user organization, businesses looking for a SaaS application should understand the advantages of an application hosted in a multi-tenant environment.

This deployment model will ensure the continuous evolution of the product, where as a SaaS application in a single tenant environment may be limited to the changes perceived to benefit the single tenant. In his article for ZDNet entitled Multi-tenancy: Why You Should Care, Phil Wainewright, leader and visionary in cloud computing, explains: “SaaS buyers shouldn’t settle for the limited horizons of single-tenancy. Multi-tenancy is the ideal architecture to make the most of the cloud environment, because it continually evolves to keep pace with the collective demands of its tenants.”

Multi-tenancy provides operational benefits because the application code is in one place making it easier and more cost effective to maintain and update. It also offers improved resource utilization, as the application and database are shared by multiple clients. Dedicated servers are no longer required, transferring the cost savings and operational efficiencies onto every customer. And despite the sharing of resources multi-tenancy provides an extremely secure environment. Consider Phil Wainewright’s apartment vs. single family home analogy. “In theory, a single house with a fence around it is much more secure than an apartment in a block shared with many other households. In practice, the householders in the apartment block will pool the cost of having a porter on duty 24×7 to control access to the building and monitor security. Most multi-tenant systems are operated to much higher security standards than standalone systems.”

This discussion just scratched the surface on the advantages and disadvantages of applications hosted in a multi-tenant environment. To learn more contact sales@navantis.com today!

This post was written by Mike Manning
At Navantis, Mike combines his passion for business and people with his technical expertise and past experience to bridge the gap between business and technology for his clients. As a Business Analyst, Mike leads requirements gathering sessions to develop use cases, and activity and dataflow diagrams that help clients understand how Microsoft technologies can optimize business process, mitigate risk and improve insights.