When sites are created for different countries, they always share the same catalog, but depending on the situation, other data sharing requirements can vary. Figure 18.1 shows the layout of sites and authorization domains.

Figure 18.1. Data sharing architecture pattern for country sites: Authorization Domain view

In this architecture, there are two top-level authorization domains: One domain is used for commerce sites, and the other is used for model sites. This arrangement is necessary because the model sites are typically administered by a central organization within the company, whereas the commerce sites are administered by the corresponding branch of the business responsible for it. Because these are different groups within the company, the roles and policies needed for model sites can be very different from those for the online commerce sites.

Thanks to multiple levels of authorization domains, administrators can be created both for each country and at the top level. In Figure 18.1, a site planner is given such a top-level role so that she can create new sites and, if necessary, deactivate and remove obsolete sites.

Figure 18.1 also shows a top-level product administrator. This person has the authority to manage site-specific products for all sites; he can also manage the catalog filter for all sites. Such central top-level administrators are needed to oversee the entire operation, with ability to access all sites. Another reason to grant roles at the top level is to simplify the role assignment process. Sometimes a company might designate a single person to administer all its sites. In this case, granting the appropriate role at the global level simplifies this assignment process: Rather than giving the role to the administrator for each site, it is sufficient to assign a single top-level role.

Figure 18.2 shows how data is divided among the model and commerce sites. In this layout, the shared catalog resides in the catalog model site, and the shared marketing and presentation data reside in the presentation model site.

Figure 18.2. Data sharing architecture pattern for country sites: Site Associations view

In many cases, it is unreasonable for all countries to use the same presentation template. Due to cultural differences and differences in market conditions, it is common to create several presentation templates, each accompanied by its own shared marketing material.

If creating these templates becomes necessary, the data sharing architecture can be easily enhanced, as shown in Figure 18.3. This figure shows both the authorization domain relationships and the site path relationships between sites and their model sites.

Figure 18.3. Data sharing architecture pattern for country sites with multiple presentation templates

This design enables the addition of as many presentation model sites as necessary as the company’s requirements evolve over time. Access to each model site is controlled by its own authorization domain. This gives the flexibility of granting administrators access only to a specific site or to all the presentation model sites. All the presentation model sites share the same role definitions through a shared, common authorization domain.

With this arrangement, all commerce sites use the same catalog model site. However, each commerce site is associated with the presentation model site that is appropriate to that market. In other words, when a site is created, the appropriate presentation model site must be selected by the site planners.

When sites must be created to suit the needs of individual market segments, the architecture pattern is typically similar to the pattern for country sites. There are separate authorization domains for commerce sites and for model sites. A single catalog model site holds the shared catalog data. Separate presentation model sites are created for the different market segments. This architecture pattern is shown in Figure 18.4.

Figure 18.4. Data sharing architecture pattern for market segment sites

In the example shown in Figure 18.4, theoretically you do not even need to create presentation model sites at all. There are only two sites, B2B and B2C, and you can simply keep the necessary presentation and marketing data in each site.

Nevertheless, it is a good idea to create presentation model sites even in this case for future extensibility. The company might decide in the future to create multiple sites within the B2B or B2C segments. If that requirement comes up in the future, it would be difficult to satisfy if the corresponding presentation model sites do not exist. On the other hand, if the presentation model sites are included in the initial architecture, it will be easy to create additional sites within each market segment.

There are several important differences in the data architecture between market segment sites and country sites. The first difference is that with market segment sites, each site might need to subscribe to a different set of roles. In our example, this is often the case due to the differences in business processes that are enabled on B2B and B2C sites. Another example would be a site designed for the government sector, in which government procurement usually has specific approval processes requiring special roles both for buyers and administrators.

Another difference is with regard to inventory management. With country sites, inventory is often managed separately for each country; therefore, inventory can be maintained within the context of each site. However, with market segment sites, usually all inventory data is shared among all sites. In the example shown in Figure 18.4, both B2B and B2C sites draw upon the same shared pool of inventory. Hence, it is correct to place inventory information within the catalog model site so that the inventory is shared by all commerce sites.

When a company sells through several different brands, typically the brands have independence in the way they manage their catalog marketing campaigns. However, there can be many variations in other data sharing requirements, such as whether the brands can share any presentation template materials. Another important factor to consider is whether each brand requires only one commerce site or whether multiple sites are anticipated.

Figure 18.5 shows the most flexible variation in which each brand has its own presentation template and also has the option to create multiple sites, such as sites for different countries. In the example, Brand A can create as many sites as it needs, each one using the brand’s shared catalog, presentation template, and marketing materials. Brand A can also create administrators who manage all the sites or who are authorized to access only one or a few of the sites. Similarly, depending on requirements, the customers of Brand A can be registered to access all the brand’s sites or only one of the sites.

Figure 18.5. Data sharing architecture pattern for brand sites

In our example, Brand B has decided that for the foreseeable future, it needs only a single site. Nevertheless, creating catalog and presentation model sites is still a good idea. Given that the commerce platform already is designed to support the concepts of data sharing, the creation of model sites for Brand B should not add any significant overhead to the implementation project. At the same time, it does enable the option of additional Brand B sites in the longer term, if such a requirement comes up.

This last point is important. The architecture of the commerce platform must be designed to be flexible and to enable not only currently known requirements, but also to support additions and growth in the company in the future. When the common data is placed into model sites, the platform enables additional sites in the future, even though at this time only one site is required.

Frequently, the data sharing architecture for company division sites can be similar to the architecture for brand sites. This is the case when each division is responsible for marketing its own set of products. From a certain point of view, a brand is a company division. For this reason, the architecture of Figure 18.5 is often appropriate for company division sites as well; just replace the word brand with division!

However, with company division sites, an additional requirement often comes up, and you need to plan for it even if initially the business does not mention it as being important. This requirement is to create a single site in which customers can find all the company’s products, for all divisions. This portal site might or might not accept orders, but its essential characteristic is to provide a single view of all the company’s products aggregated from all the divisions. The data sharing architecture for this requirement is shown in Figure 18.6.

Figure 18.6. Data sharing architecture pattern for company division sites

With this arrangement, each division has its own presentation and catalog model sites and therefore controls its catalog, marketing, and presentation template. Furthermore, each division can create as many sites as it needs—for example, selling to different countries or to different market segments.

At the same time, there is a company portal site that combines the catalogs of all divisions. This is achieved by associating the portal site with multiple catalog model sites. Figure 18.7 shows the site associations required for this arrangement.

Figure 18.7. Site associations for company division sites

The architecture allows each division to have multiple sites. Each of the division’s sites is associated with the division’s catalog and presentation model sites; in this way, creating a site for each division is an easy process because most of the necessary data is already available.

The company portal site is associated with all the catalog model sites, and as a result, its catalog is aggregated from all the division catalogs. In this example, the company needs only a single portal site, and all the necessary presentation and marketing information resides directly in the portal site. Consequently, the company portal site is not associated with any presentation model site.

Another variation of data sharing setup for company division sites is shown in Figure 18.8. In this example, to maintain a single brand image, the company wants all its sites to look the same; in other words, all the sites must share the same presentation template. At the same time, each division needs to maintain independence in its management of catalog and marketing information.

Figure 18.8. Site associations for company division sites with shared presentation

To achieve this requirement, we break up the marketing information from the presentation model site so that now we have three types of model sites:

With the new type of model site, added flexibility in the kinds of associations can be made. Each division’s site is associated with the division’s catalog and marketing model sites and the company’s presentation model site. The company portal site is associated with all catalog model sites and the presentation model site. The overall data sharing architecture for this scenario is shown in Figure 18.9.

Figure 18.9. Data sharing architecture for company division sites with shared presentation

As a result of this arrangement, all the company’s sites automatically look consistent with each other because they use the same presentation template. However, each division manages its own marketing campaigns and catalog. The company portal site also manages its own marketing campaigns and uses the catalog aggregated from the divisions.

The examples of data sharing architecture we have considered so far are confined to single-purpose scenarios. In other words, in each example the company is involved in a single business scenario, such as country sites or market segment sites. However, in reality, usually a company needs to create sites for many scenarios. For example, it might have multiple brands, and each brand needs to create sites for many countries and many market segments. Or it can have multiple divisions, and each division sells to different market segments to many countries. The company can create sites for different market segments in different countries, and customized sites for large customers; in some cases, each customer can have different sites in different countries.

To better illustrate the effectiveness of data sharing architecture, let’s consider such a combined scenario. We look at an example in which the company has the following characteristics:

There are several interesting challenges in this situation. One challenge is dealing with inventory. We will assume that each country has its own inventory; that is, all the sites within each country must share the same inventory pool. Another challenge is ensuring that large customer sites have the flexibility to customize presentation and business rules and yet follow the company’s overall presentation style. Finally, the partner sites need to be managed completely separately, but they still participate in the overall architecture by sharing the company’s catalog.

Figure 18.10 shows the authorization domain view of a possible data sharing architecture for this scenario.

Figure 18.10. Data sharing architecture for combined scenario: Authorization Domain view

One important feature of this architecture is that it allows for two separate authorization domain infrastructures: one for partner sites and the other for direct sales sites. Both infrastructures allow for model sites and commerce sites. This way, each part of the company’s business can be completely independent in how it manages its sites, to the point of having the capability to create its own roles and access control policies.

In spite of having such flexibility in site management, all commerce sites from both authorization domain infrastructures share the same catalog model site. This is necessary because the partner sites and the company’s commerce sites all use the same master catalog of the company’s products. The capability to share the same catalog is an important benefit to using the same platform for these completely different sites, and the common catalog model site makes this easy to achieve.

The authorization domain hierarchy is designed to give maximum flexibility in assigning access to groups of sites. With the arrangement in Figure 18.10, you can assign an administrator access to any single site. You can also assign a single administrator to manage both the B2B and B2C sites in any country. An administrator or a customer profile can also be created to have access to all the sites of any given large customer.

Figure 18.11 shows some of the necessary site associations for this scenario. All sites reference the same catalog model site. Each site also references the inventory model site for the country it serves. In addition, the B2C commerce sites are associated with the B2C presentation model site, while the B2B sites and large customer sites are associated with the B2B presentation model site.

Figure 18.11. Site associations for combined scenario

In Figure 18.11, we assume that the large customer sites are generally based on the B2B presentation template. With the site path data sharing technique, a large customer site can override any aspect of the presentation template—for example, replacing pages or adding additional pages.

Furthermore, a large customer site might contain additional products created specifically for that customer. You can even create an additional catalog model site for a customer so that all the customer’s sites share the same custom products, although we did not show it in our example.

A great deal of flexibility is available with the data sharing techniques based on authorization domains and site path, and with careful design you can satisfy a wide range of different requirements.

We have seen that data sharing architecture must reflect the company’s business requirements, and allow room for growth and to add additional sites as the business evolves. The architecture needs to be built to be extensible from the start.

A good analogy to use is building a house. Let’s say a family with one child builds a house with two bedrooms and two bathrooms. At the time when the family makes the purchase, this house is quite sufficient for their needs. However, let’s say that the following year they decide to have another baby and learn that they will be having twins!

Now the family definitely needs to create at least one more room in the house and ideally one more bathroom as well. The family is therefore faced with a choice to either move to a bigger house or renovate their existing home to add more living space. Moving to a bigger house can be expensive. The move would also be disruptive and unpleasant, especially if the family only moved into their current house recently. At the same time, renovations are also expensive and can also be disruptive to their lives, with all the contractors and the building dust.

If the family considered the possibility of adding children when originally building the new house, they could have planned for this situation, with an additional investment into the design of the house. For example, they could have rafted in plumbing for an extra washroom. Initially, the additional bathroom was not necessary, so they didn’t need to pay for it. However, with the relatively small initial investment, putting it in now is a relatively small job.

Similarly, they could have made sure that the house was big enough and had areas that could be reconfigured into additional rooms if that becomes necessary, without having to upset existing plumbing, linen closets, or electrical wiring. Thus, when expansion becomes necessary, they can do it at minimal cost, with the least amount of time, and with the least disruption to their lives.

The same concepts apply when creating a multisite commerce platform, where it is important to plan for long-term growth beyond the currently known requirements. To illustrate this scenario, consider the example of brand sites. We mentioned when describing Figure 18.5 that if Brand B needs to create only one site, there actually is no need to create a presentation model site for that brand. In other words, because no data is shared between sites, it might be tempting to create a simple architecture that allows for only one site for this brand. Such simplified architecture is shown in Figure 18.12.

Figure 18.12. Brand sites architecture with no provision for data sharing for one of the brands

In this simplified architecture, Brand A has its model sites; therefore, it can easily create additional sites if necessary. However, the Brand B site does not make use of any model sites, but instead all its data is created in the context of the commerce site.

Later, it is possible that Brand B might decide that it actually does need additional sites. For example, it might decide to create sites targeted to other countries, or perhaps it might want to create smaller associated sub-brand sites for specific market segments. In other words, Brand B decides to have the capability that Brand A already has.

However, at that point it will be difficult and expensive to remodel the architecture to enable this data sharing. The remodeling process requires the creation of the missing model sites and moving the Brand B data to those sites. This can involve a large amount of data, such as the catalog, marketing, and presentation data.

In the preceding example, we see how painful the process is to re-architect a commerce platform. This transition from nonshared architecture to shared architecture is typically an involved process that requires the expenditure of significant resources, the involvement of highly qualified personnel, and careful testing. The worst part of it is not necessarily the technical difficulties encountered and not even the cost of the work. Rather, the most risky aspect is that it can cause disruptions to the existing customers. Such issues as downtime necessary for the transition or breaking old links to the existing site can end up costing the company’s site its most valuable asset of all, namely customer loyalty.

With the help of experienced architects and designers, and with the investment of sufficient resources, the disruptions due to the transition could be minimized. However, it is certainly much better if the platform’s architecture is designed from the start to accommodate the future data sharing requirements so that a massive remodeling effort is not required.

In the design of a multisite platform, the data sharing architecture must be considered an integral part of the overall architecture of the system. The data sharing architecture is concerned with the arrangement of authorization domains and model sites within the platform. The data sharing architecture determines the kinds of data to be shared and how the shared data is to be made available to commerce sites.

A number of data sharing architecture patterns can be applied to typical business situations, such as sites created for different countries, market segments, brands, and company divisions. Although no two companies are exactly the same in their data sharing needs, these architecture patterns can be tuned to the needs of each individual scenario.

In addition, you can use the concepts of authorization domains and model sites to put together a more complex architecture that satisfies the needs of a large company with sophisticated data sharing needs. The data sharing architecture must be designed to be flexible and extensible to accommodate additional requirements that might come up in the future.

We conclude that data sharing architecture is critical to the success of a multisite commerce platform. The data sharing architecture must be designed to be flexible and extensible to accommodate additional requirements that might arise in the future. With a good architecture, the shared commerce platform can be used to create and administer the company’s many different commerce sites, even as the business evolves over the years to come.