Understanding Realms and Sites in SFCC

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.

Realms in 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.

Sites in SFCC

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.

Architecture of Site and Realm

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:

Shared Objects

• Inventory | Pricing | Products and Product Photography | Custom Code | Customers | Content Assets

Site Specific Objects

• Content Slots | Orders | Promotions | Site Preferences/Configurations

Single Realm vs. Multiple – Which Approach is Better?

Each approach has its pros and cons. Let’s go through the details.

Single Realm

Pros:

1. Leverage same core code base.
2. Easy to maintain.
3. Better for small teams.

Cons:

1. Customization specific to the site is difficult and hard to maintain.
2. A shared code base dictates the business requirement. A functionality becomes a priority only if it benefits all brands and not for a specific requirement of an individual brand.
3. Roll-out or Release (good or bad) for global code affects all brands.

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:

• Data Replication | Code Deployment | User Rights and Administration

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.

Multiple Realm

Pros:

1. Flexibility in having different code and functionality.
2. The global code will not affect all brands – it will only affect the brands in that Realm.
3. Different business requirements or logic can run independently if the code is for a different brand.

Cons:

• Higher infrastructure cost.
• A new STG, QA, PROD instance is required to push code from lower environment to a production environment.
• New Sandboxes are required since a different set of code is being developed and maintain.

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:

• By having alignment between business units or brands or regions.
• By identifying and acknowledging organizational constraints or culture which make alignment difficult to attain.

Conclusion

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:

• Allow a site – or a set of sites – to move from shared Realm to one of their own, as business results justify the financial aspect.
• Alternatively, merging site(s) from multiple Realms into a single Realm is a bit more of a challenge as it likely requires code refactoring.

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.