If you are managing multiple brands/websites on SFCC, then you must have encountered a pertinent question – Should you utilize multiple Realms for developing/configuring/managing multiple websites, or opt for a single Realm for all of them? Finding the correct answer to this question is crucial to improve efficiency and scalability as well as meeting business objectives.
In this blog, we would try to explain the relationship between Realms and Sites, and outline the benefits and limitations of using a single Realm in comparison to multiple with respect to business objectives.
Before diving deep in the subject, it is important to understand what the terms ‘Realms’ and ‘Sites’ refer to in the context of SFCC.
A Realm is a piece of the Salesforce Commerce Cloud that describes the aggregation of service (both software and hardware) that Salesforce provides to their customers. Further, a Realm contains instances, which are application infrastructure that includes Web servers, Application servers, and Database servers. Typically, a Realm consists of two groups: the primary instance group (PIG) and the secondary instance group (SIG).
A customer receives 9 instances per Realm - 3 instances for staging, testing, and deployment on the PIG and 5 sandbox instances for code development on the SIG. To scale, customers can have up to 47 sandboxes per Realm (most of which are available for a fee). A specific point of delivery (POD) serves the Realm, located in a single data center.
Each Realm can host as many sites as you want to create. There is no commercial impact on measurement system analysis (MSA). The calculation of the subscription fee depends on gross merchandise value (GMV) sum within a Realm. Sites within a realm generally share an admin, development, and operations team. These sites can also share code (via their cartridge path) and business objects like product data, category structure, content library, and customers list. Each site comes with a dedicated inventory module.
A Realm is designed to host multiple sites.
Designs of the data objects inside a Realm are shareable across all sites within the Realm and can be local to a specific site. For example:
Site Specific Objects
Each approach has its pros and cons. Let’s go through the details.
When to opt for the Single Realm Approach
The sites within a Realm have an inherent relationship with regards to their management – specifically related to operational and administrative tasks such as:
Since many objects are shareable across all sites within a Realm, a business can streamline merchandising, development, QA, support, and maintenance of their sites within a Realm. This streamlining creates significant efficiencies and scalability when compared against solutions that include redundant processes and multiple databases that need synchronization.
Generally, all sites within a Realm share a merchandising team or at least reflect a business where the merchandising teams work collaboratively on schedules, processes, and priorities. They also share an admin, development, and operations team. Code, jobs, processes, and functionality needs to be scheduled, prioritized, and configured in such a way to address the needs of all sites within the Realm. On the downside, creating individual control at site level in these areas is nearly impossible within a Realm due to inherent sharing, which is architected within the sites in a Realm.
Note: This sharing does not limit the differentiation of sites within a Realm but does limit the business processes and operating models of the sites within a single Realm.
When to opt for the Multiple Realm Approach
Customers who use this approach, in general, have different partners or development teams responsible for the site in each unique Realm. These customers also have business teams who can define, prioritize, fund, and execute initiatives independently from each other (this usually means their P&L report into different business units).
Customers who leverage multiple Realms benefit from the differentiation in how business processes are defined and managed while benefiting (in an offline manner) from the native compatibility of the SFCC architecture (importing or exporting from Real to Realm is easy).
How to work around brand consistency issues with multiple Realm approach:
|Single Realm||Multiple Realm|
|Single Partner or Development Team||Multiple Partners or Development Teams|
|Common Code and Release Schedules||Divergent Code and Release Schedules|
|Shared Merchandising Practices (common view)||Divergent Merchandising Practices (isolation)|
|Shared Support and Maintenance Team||Divergent Support and Maintenance Team|
|Common Project Prioritization and Resourcing||Unique Project Prioritization and Resourcing|
|Shared User Rights Management||Unique User Rights Management|
Realm architecture (single or multiple) is a decision that has both financial and operational implications. However, since code and data are transportable between Realms, it is possible to re-architect the user of Realms over time as the business evolves. For example:
Regardless of the commercial impact of the multiple Realms approach, architecting a single Realm solution where multiple Realms are needed should be avoided at all costs as it will make it difficult (if not impossible) to achieve the business objectives.