The commerce platform used by a company consists of hardware, software, and administrative services necessary to maintain the operations. It is important that each requirement is met by the overall platform, and not only by a specific component of it. For this purpose, we can apply a corollary of the well-known Amdahl’s law of computers.

Amdahl’s law was articulated in the 1960s as engineers were trying to find ways of building faster computers. It states that a computer cannot work any faster than its slowest component. Intuitively, this statement makes sense: You can have a super-fast processor, but if the memory is slow, the computer will not run very fast.

The same rule applies to many things in life, such as business processes. For example, let’s say your order management and fulfillment are very fast, but due to poor inventory management there are frequent delays because items need to be backordered. Then, from the customer’s point of view, your company is slow at shipping orders.

And getting back to our subject, the corollary of Amdahl’s law is that a commerce platform is only as good as its worst-implemented requirements. You can develop a platform that makes it easy for the business to create and manage the global catalog and then adjust it to the needs of each site with minimal effort. However, if your key requirements also include the capability to share marketing collateral or marketing campaigns among sites, and this feature is not enabled, despite all the excellence in catalog management, the overall platform might not be suitable for the business.

Similarly, if you need to create many dozens of sites for different niche market segments, it is important that order management be done by a single organization that can see and work on orders from all sites, rather than one site at a time. If the platform does not provide efficient order management capability, the business might not make use of it because order management costs would exceed any benefits from the increased revenue of targeted sites.

One more example of the need to consider the requirements for the overall platform is with regard to scalability and performance. The platform might enable the business to create sites that the lines of business could only dream about and even provide excellent tools to administer all aspects of the sites. However, the company must also consider such factors as the maximum number of sites that will be necessary, the number of estimated customers using the sites, and the number of orders that will be created on each site. These considerations have nothing to do with the functional aspects of the platform, but they are just as important. If the platform does not scale up to the demand of the company’s sites, or if the sites end up being too slow for customers to use, the platform is useless and the company cannot employ it in its business.

The set of requirements presented in this chapter were accumulated from experience with a large number of situations encountered in the field. By no means do we assert that this list is 100 percent complete, and it is entirely possible that some requirements are not present. Each industry is inherently unique, and even each business within the industry always has its own peculiarities that result in specific requirements. In some cases, we omitted requirements that were deemed not to be sufficiently pervasive and applicable to all situations. It is also possible that you might have additional requirements that we never thought of. Furthermore, depending on each individual situation, a company might find that some requirements in the list here do not apply to it.

However, the list compiled here is a representative collection of the kinds of requirements typically encountered so that you are aware of the breadth of this field.

Site planning is concerned with such tasks as creating new sites, shutting down or “sunsetting” obsolete sites, and assigning administrators to manage sites.

Managing Site Administrators

Each site operated on the shared commerce platform must have administrators who are responsible for tasks such as catalog management, marketing campaigns, or order management. An important task typically carried out by central administrators of the platform is that initially, when sites are created, administrators must be assigned to each site responsible for managing each type of information.

Administering an individual site on a shared platform is not much different from administering a site when the platform is not shared. In both cases, typically the responsibilities are divided into a set of roles, and users are created and granted the roles that they need within their areas of responsibility. In addition to having roles, sometimes users might need access to specific resources managed by the site, such as a customer territory or the categories within the catalog that they need to view or to modify. This scenario is illustrated in Figure 8.1.

Figure 8.1. Administrator roles and resources

The main difference introduced when a single platform is used to operate multiple sites is that frequently an administrator requires access to more than one site. For example, a customer service representative might need to create or modify orders for both consumers and business customers, thereby requiring administrative access to both B2B and B2C sites. Another example is a single call center in India that might be responsible for providing service to customers from many English-speaking countries, such as the United States, Canada, the United Kingdom, and Australia. This scenario is illustrated in Figure 8.2.

Figure 8.2. Roles for accessing multiple sites

Sometimes the situation is more complex, and administrators need to be assigned different roles depending on which site they work on. For example, a sales manager on one site might need access on another site; however, on the second site, this administrator does not create orders but only administers existing orders. This scenario is illustrated in Figure 8.3.

Figure 8.3. Different roles for accessing multiple sites

The requirement, then, is that when a new site is created, new administrators can be assigned to the site, either by granting the additional access to existing administrators or by creating new ones.

Frequently, it helps to arrange the sites in a tree-like structure, as shown in Figure 8.4. In this example, Administrator 2 manages the products for all the company’s sites. Administrator 4 acts as customer service representative for all sites in Canada. Administrator 1 acts as a sales manager for site 1 and as an order administrator for site 3.

Figure 8.4. Assigning access to groups of sites

This arrangement makes the management of administrators easier and less time-consuming because by a single assignment we can grant access to many sites. At the same time, this concept of groups of sites introduces a complexity into the structure of the sites; this requires careful initial design to ensure that the structure of this tree of sites suits the company’s needs. Enabling such access to groups of sites also requires comprehensive training of the site planning personnel so that they can determine the correct role assignments that need to be done.

Summary of administrator management requirements:

• Site managers need to create administrators and assign them roles and access rights to resources within a site.

• Site managers need to assign roles and access rights to an administrator for groups of sites.

From the point of view of site flow and presentation, a platform that is used for multiple sites must enable the IT personnel to create several presentation templates and allow each site to select the presentation template appropriate to it. This selection can either take place initially when the site is created, or an extra degree of sophistication could allow the site administrators to choose a different presentation style later during the site’s operation.

Other than choosing the presentation template, each site must have additional options to vary its presentation, such as changing the position of the navigation bar or changing the color scheme. It might also be useful for site administrators to turn on or off certain features of the site. For example, say a B2B company needs the capability for customers to submit requests for a quote, but this is required only for the U.S. and Canadian sites, and not yet supported in Europe. In this case, it would be useful for European site administrators to be able to turn off this feature within the presentation template, whereas in the United States and Canada it would be turned on.

Another important requirement of site presentation is that site administrators must be able to put up messages specific to their sites, such as a welcome message, news announcement, legal disclaimer, or privacy statement. Depending on the sophistication of the operation, the administrators might need these messages to be only text, or they might need to create rich multimedia messages, including graphic images and even video clips or sounds.

Finally, for a truly unique site, such as a site created for a distinct brand, it might be necessary to create a presentation template and style unique to that site and not shared with other sites as a presentation template. Although creating and maintaining the presentation material for such a site would be expensive, doing so might be necessary to maintain the uniqueness of the site, and it would be undesirable to allow other sites to reuse or have access to this presentation template.

Summary of presentation requirements:

The key requirement for catalog management is that catalog information needs to be shared among sites. However, the sharing of catalog information must not be all-or-nothing, where the entire catalog, including all products and categories, becomes visible on all sites. Rather, catalog administrators of each site must be able to select the categories and even products that should be displayed on their site; alternatively, they might prefer to select the categories and products that should be excluded from that site. This selection of products and categories to be used on a site is the job of the line of business team and should not require any involvement from IT personnel.

Catalog inclusions or exclusions must be pervasive in the site so that an excluded product cannot be shown or purchased in any way on that site. For example, let’s say there is an item called “product A,” and it has a cross-sell called “product B.” Normally, when shoppers add product A to their shopping cart, they are also shown product B. If, however, product B or its category is excluded from the site’s catalog, this cross-sell should not show up even when product A is displayed. Similarly, no advertisements or promotions for product B should be displayed on the site that excludes this product.

In some cases, site administrators need to create and manage products or entire categories applicable only to that site and not shared among multiple sites. For example, such products could be created for the unique needs of a large customer and are made available only on the customer’s site.

These site-specific products might be entirely new, or they can be bundles of products drawn from the master catalog. In either case, when site catalog administrators create such new products, they must be able to create all the associated information that enables customers to search for, view, and purchase the products. For example, they need to place products within the catalog hierarchy, assigning it to the correct categories, and create all the collateral information for the additional products or categories, including any descriptions or rich media, and even create any associated up-sells or cross-sells.

In some cases, such products might need to be visible in more than one site, but not in all sites. In this situation, the administrators have a choice on how to approach this task. They could create the product in the master catalog shared among all sites and then inform all affected sites to exclude the product if they do not want it to be available on their site. Alternatively, it would be useful to create a product or category and share it with only a group of sites. This approach can be somewhat similar to the way administrators need to be assigned to groups of sites, except that the groups of sites here share catalog information rather than administration rights.

Another aspect of catalog data that administrators must manage is pricing. The common platform must allow both the sharing of prices among sites and overriding the prices within a site. Such overrides frequently take the form of a site-specific price list, which is used only within the site. Alternatively, the site might want to make use of the master pricing data managed with the master catalog and provide percentage adjustments, either uplifts or reductions, to other products or categories. The advantage of such percentage uplifts or reductions is that they remove the need for site administrators to manage the price point of each product, allowing them instead to create only a small number of broad rules that are much easier to manage.

Summary of catalog management requirements:

We have seen two approaches to sharing marketing campaigns among sites. The first is to create marketing collateral centrally and share it among multiple sites, so that creation of marketing activities is easy for all sites in support of global marketing campaigns.

The other approach is to create a marketing campaign and make it appear on all sites, without the involvement of administrators of each site. As we described in Chapter 4, “Sharing and Caring,” this approach is rarely useful but can be applicable for some global campaigns that are limited to advertising. However, even in this case, it might be necessary to create such shared campaigns for only some of the sites—for example, only for sites in Europe, or only for consumer sites but not for B2B sites. Additionally, each individual site must have to ability to opt out of such a campaign; that way, even if the central administrators create a global shared campaign, some individual sites can still have the option of not showing it.

Summary of marketing campaign administration requirements:

Order management requirements can vary greatly depending on the reason the business has created multiple sites. For example, typically, for country sites, orders exist in the context of each site and are managed only in that context. Thus, if customer service representatives need to find and modify a customer’s order, it is reasonable for them to first have to go to the site of the customer’s country.

On the other hand, if sites are maintained for each of a company’s divisions, it is more convenient for the company to look for orders and manage them globally across all sites. This way, if customers look for an order, they or customer service representatives would search for it across all sites based on customer’s name, approximate time the order was placed, and perhaps other information about the order, such as the products it contains.

Frequently, both types of order management are required so that some groups of sites need their orders managed together, and other sites insist on having their orders managed separately within their own domain. It is therefore a requirement that the shared commerce platform allows administrators and customer service representatives the option of searching for orders and managing them within a group of sites. The authorized administrator needs to sell all orders within these sites, without having to access each site separately and manage orders within it. At the same time, administrators must also view orders in the context of an individual site.

Summary of order management requirements:

Often a single customer needs to access several sites operated by a company’s divisions. From the customer’s point of view, such access must be seamless so that she never has to reinput her address or payment information, and the single customer profile is consistently available to all sites the customer uses. If a customer has business contractual arrangements with the selling company, usually the same terms and conditions should be applicable to all sites that the customer uses. Therefore, a requirement for site administrators is to grant a customer access to multiple sites, whether this customer is a consumer or a business.

If a customer’s profile is revoked, that customer loses access to her profile in all the sites she was registered to.

In other cases, however, when customers access different sites, the company prefers them to be completely unaware that these sites are in fact on the same platform. Instead, these customers view the sites as completely unrelated to each other and maintain separate profiles for them.

Summary of customer management requirements:

We have discussed that a large commerce operation has a huge volume of data that needs to be regularly updated. We have also described that many different administrators can be involved in updating the data, such as catalog administrators, marketing administrators, and so on. However, typically, the IT infrastructure for commerce sites is set up in such a way that the administrators cannot directly modify the catalog or the marketing campaigns shown on the commerce site. Instead, the administrators create and change data only in what’s known as a staging environment or quality assurance environment. This concept is illustrated in Figure 8.5.

Figure 8.5. Quality assurance environment for commerce sites

The production environment contains the actual live sites made available to customers. The quality assurance environment contains all the same sites, except they are not made available to customers, but only to personnel involved in administration and testing of sites.

Any necessary changes are normally done by administrators only in the quality assurance environment. Similarly, if a large amount of new or modified data needs to be loaded, this is done in the quality assurance environment. After the administrators have finished changing the sites or creating the new catalog or marketing data, the testers can preview the sites in this environment to make sure that all the changes are acceptable.

Only after the information is tested can it be approved to be made available to customers, which is accomplished by promoting the changes from quality assurance into the production environment.

Companies have used many methodologies and technologies to ensure such quality assurance of commerce data, and here is not the place to elaborate on these technologies. The issue relevant here is that when a single platform is used for multiple sites, most likely the administrators of several sites are editing the data at the same time. Hence, this quality assurance environment and the associated processes must be able to deal with changes happening to multiple sites at once.

The simultaneous administration by all sites makes quality assurance particularly complex. One site’s administrators might have completed a project and now need to start previewing and testing their changes, whereas other sites are not yet ready to test their changes. After a site’s administrators have approved the changes, they will want to propagate them to the production environment; however, in this case, it is vital to make sure that only the approved data is propagated, that is, only the data associated with the site or sites that have been tested.

This multisite quality assurance environment is illustrated in Figure 8.6.

Figure 8.6. Quality assurance environment for a platform with multiple sites

What we see is that the administrators of each site might be working on multiple projects. Any project, when completed, must be tested independently of other projects, and then the changes relevant only to that project and to that site propagated to the production environment.

A more complex situation arises when shared data is being changed, such as the global catalog or collateral used by marketing campaigns in many sites. In this case, changes to shared data will affect all sites that make use of that data. For example, if a new product is added to a category, all sites that have not excluded that category from their catalog will automatically be showing the new product. Therefore, part of the project involving modifying shared data can involve administrators of individual sites making changes necessary to ensure the new data is acceptable within their sites.

Another important aspect of changing shared data is that the changes must be tested in the context of all the sites that make use of that data. Therefore, this project to create or modify shared data must involve quality assurance personnel who have the ability to preview and test changes in the quality assurance environment for any site.

The project for modification of data shared by multiple sites is shown in Figure 8.7.

Figure 8.7. Quality assurance environment when shared data is updated and previewed

With such a project, it is not sufficient to simply allow each site to have its own scope of changes, isolated from other sites. Rather, this project involves both central administrators responsible for management of shared data and the administrators of individual sites. Many administrators work on these complex multisite projects simultaneously, and they test and preview the changes in the context of multiple sites. When finally changes are propagated to the production environment, they affect customers on all the sites that make use of the shared data.

Summary of quality assurance requirements:

From the customers’ point of view, site performance is the amount of time that customers have to wait after every click on the site. Similarly, administrative performance measures how fast the site responds to requests by administrators. Every company wants its commerce sites to be as fast as possible. The goal is to ensure that customers are not annoyed by having to wait a long time after each click and also to ensure that administration tasks can be carried out as fast as possible.

Performance requirements for a site hosted by a shared platform along with many other sites are no different from performance requirements for an independently managed and hosted site. However, one aspect of performance is unique to a shared commerce site platform: It has to do with the scalability of the platform or how well the platform responds to the rising traffic on some sites.

Let’s imagine a situation in which two sites share the same platform. One of them is extremely busy, but the other is not heavily used. For example, during the holiday shopping season, you would expect traffic on the consumer site to be really heavy, whereas the load on the B2B site might be average or even relatively low.

In this situation, you do not want to assign the same computing resources to both sites. If you do that, the capacity of the overall system will be sitting unused due to low traffic, whereas the consumer site will be slow because it cannot handle all the traffic. The desired behavior is that the operational environment will automatically adjust itself so that each site has optimal performance at all times.

Another important aspect to consider is that the platform must scale up as the number of sites grows. When each additional site is created, there should be as little impact as possible to the performance of all other sites. In some cases, a company might need to create hundreds, or even thousands, of sites, and it is important that the platform can handle as many sites as the business needs.

Summary of performance and scalability requirements:

When multiple sites share the same platform, resilience can become a key question that the company must address. Each division of the company certainly wants its sites to be available to customers 24 hours a day, 7 days a week. However, in real life, service interruptions can occur. The IT department can anticipate and plan for some interruptions such as system updates. However, interruptions can also happen unexpectedly due to system failures coming from software or hardware, as a result of mistakes by administrators, or even from overload due to unexpectedly high customer traffic on the sites.

What every company division would be afraid of in the shared environment is that its site would become nonoperational, or down, due to conditions caused by other sites. The following example describes a possible situation in which a defect in one site can adversely affect all other sites on the platform.

This scenario shows how mistakes made on one site could negatively affect other sites. The worst case scenario, of course, occurs when a problem with logic or data that is specific to one site causes the entire platform to go down, which can cause enormous losses to the company.

It is therefore extremely important for the shared platform to ensure resilience, where problems are confined to the scope of a small number of sites but do not affect all sites. A number of techniques can be employed to promote such resilience, which can take the form of instituting operational procedures to be followed by administrators, of rigorous quality control, and of software- or hardware-based techniques.

The other aspect of resilience is that following a system shutdown, either planned or accidental, IT personnel should restart all sites quickly and easily. We definitely want to avoid a situation in which each site must be started manually one by one, but rather all sites should be made operational with a simple procedure.

Summary of resilience requirements:

In any business system, whether computer based or manually operated, security should never be treated as an afterthought but must be considered at the earliest stages of system development. When many sites share the same platform, security of information among sites is not just important, it is absolutely essential for the platform to be usable by the company.

The question of commerce site security has been made famous by such lapses as loss of personal and credit card information, hacker attacks and site defacements, and malicious administrators. Here we focus only on the issues created by having multiple sites reside on the same platform. Security issues can be classified by their origin—namely, issues originating with a site’s real or malicious customers, with real or malicious administrators, and with healthy or defective computer systems.

In this chapter we described some typical requirements that must be satisfied so that a multisite commerce platform can serve the needs of a large company. Each area of requirements is important, and a company must consider all the requirements to determine the suitability of a proposed platform.

The requirements we discussed came from the following areas:

We must again emphasize that this is not intended to be a complete list of requirements applicable to all companies, and indeed it would be futile to attempt to create such a list. Instead, we focused only on those aspects of requirements that are usually necessary to enable a company to use a single commerce platform for its multiple commerce sites.