Microsoft Commerce Server 2000: Project Goals and Requirements

This chapter describes how to plan your Microsoft Commerce Server 2000 implementation to accomplish your business goals. A successful Commerce Server implementation requires a clearly defined vision of what you want to accomplish. By thoroughly examining and planning your e-commerce site before installation, you can significantly increase the efficiency and availability of the services your site provides, ensure the general success of your site, and make sure that your goals are accurately reflected in future phases of the project.

Planning is the first phase in the Plan-Develop-Deploy-Manage cycle. The following table shows the two documents you create during the Planning phase.

Document	Activities
Project Goals and Requirements	Define project goals and scope. Develop a conceptual design. Define your requirements for the new e-commerce site: What do you want to accomplish? Plan for migration.
Project Plan	Create a functional specification to define the new e-commerce site. Identify the project team. Develop a project schedule. Develop a project budget.

For more information about the Project Goals and Requirements document and the Project Plan document, see Chapter 5, "Planning for Scalability," Chapter 6, "Planning for Reliability and High Availability," and Chapter 7, "Building the Project Plan."

The Planning phase is critical to the success of your project. To ensure that you have all the essential information you need during the planning process, you should include the team members listed in the following table.

Team members	Tasks
Company executives	Define project goals and scope (with other team members) Approve the conceptual design Define project requirements (with other team members) Approve the functional specification Approve the project schedule Approve the project budget Allocate resources for development, deployment, and management
Marketing and sales personnel	Define project goals and scope (with other team members) Approve the conceptual design Define project requirements (with other team members) Approve the functional specification Approve the project schedule
Site developers and system administrators	Create the conceptual design Define project requirements (with other team members) Plan for migration Create the functional specification Create a project schedule Propose a project budget Propose a list of project team members

Figure 4.1 illustrates the tasks that you need to complete during the Planning phase.

 

Figure 4.1 Planning phase 

The following sections provide detailed information about how to plan your Commerce Server implementation. The Planning phase is complete when your company accepts a finished Project Plan. The Project Plan is then used by project team members to develop and deploy the site.

Creating a Project Goals and Requirements Document

The Project Goals and Requirements document contains the following information:

• Project vision and scope (including project constraints, assumptions, and risks)

• Conceptual design

• Requirement definitions

• Commerce Server features

• Migration plan

This document is used as the basis for creating the Project Plan. Begin the planning process by defining project vision and scope (given the schedule and constraints). Asking the questions listed in this section, among others, will help you to define these elements.

Vision

A comprehensive vision statement is a tool that empowers the entire organization to work together to build a successful e-commerce site. The following table describes the elements of a comprehensive vision statement.

Element	Description
Clarification	Team members need to know what they are trying to build—both what the project includes and what it does not include.
Prioritization	Since there is never enough time to do everything, a vision statement should rank project priorities.
Integration	Your vision statement must complement and support the visions of other company projects. Other projects might serve the same customer markets as yours, and some might have overlapping feature sets. Your vision statement should describe how your project will integrate with other company projects.
Future investment	Not only should your vision statement guide the current project, it should also plan for the future. For example, if developers know that you plan to build a business-to-business site in the next version, they might begin to think about Internet delays and low bandwidth issues as they architect this version. Foresight can save time and money in the future.

When you define the clarification, prioritization, integration, and future investment elements that comprise your vision statement, you should make them S-M-A-R-T:

S = Specific
M = Measurable
A = Achievable
R = Relevant
T = Time-based

Your vision statement should answer the following questions:

• At a high level, what outcome or result do we envision for the project?

• Why are we pursuing this solution?

• Who are our customers?

• What problem does this solution solve for our customers?

• What else is the company doing at the same time?

For example, the following is a hypothetical vision statement for a Web server migration project:

"Our company will replace its current UNIX Apache Web server environment with a Windows 2000 Server and IIS 5.0, a more efficient and flexible solution that will maximize competitiveness in our industry while reducing operational and administrative costs. The company will implement a global Windows 2000 Server domain model and will begin a scheduled deployment program to 20,000 worldwide users at 100 locations by the third quarter of 2001. We will start an enterprise-wide rollout within three months and will be user-complete within 18 months, or the first quarter of 2002. Implementation will require a conversion and coexistence infrastructure in order to seamlessly move users to the new platform. To accomplish this, we will use Windows 2000 Server integration tools and third-party UNIX conversion tools."

After you draft your vision statement, you should start "selling" the vision and getting the rest of the team involved. Get approval from upper management, incorporate other people's expertise, and get the team excited about realizing the vision. Gather feedback and verify that team members understand the vision and its goals. Then incorporate that feedback into the vision statement, or justify not incorporating it, if necessary.

Scope

To determine the scope of your project, answer the following questions:

• What type of site (for example, business-to-consumer or business-to-business) do we want to build?

• What features can we reasonably implement during the time allotted for this project?

• What features do we want to postpone to a later date?

Project variables, such as resources (people and money), schedule (time), and features (the solution) exist in a triangular relationship, as shown in Figure 4.2.

 

Figure 4.2 Project variables 

Setting project scope requires balancing these variables. For example, you might need to eliminate non-critical features in order to complete the project on time or with fewer resources. If eliminating features is not an option, you might need to add resources or extend development time in order to complete the specified features.

Constraints

Identify project constraints by answering the following questions:

• What is the estimated project budget?

• What is the target release date?

• What constrains the project from finishing on time, on budget, or with the functionality we want?

For example, list any time, personnel, budgetary, or other factors that limit project development options in your Project Goals and Requirements document.

Assumptions

List your assumptions so that other team members and management can understand the basis for your design decisions. By making your assumptions known, you also provide the opportunity for others to challenge, correct, and verify your assumptions, if necessary. This feedback can be valuable information for the planning process. For example, you might assume that a Microsoft Windows 2000 Server domain design has been implemented, or that qualified personnel are available, in order to meet the specified schedule. If other team members know that the domain design has not been implemented or that the budget does not provide for more personnel, you need to know that information before you start. These assumptions should be clearly stated in your Project Goals and Requirements document.

Risks

By analyzing risks before you begin a project and implementing methods to mitigate them, you can reduce their impact on your project. The first thing to do when you consider possible project risks is to make a list of the things that can go wrong, then develop strategies for mitigating them. As the project proceeds, your project team can periodically reexamine the risks, review mitigation actions, and decide how well each risk is being managed. The following table lists some examples of high-level project risks and mitigation strategies.

Risk	Mitigation strategy
Site downtime	Test servers prior to deployment. Test all applications prior to deployment. Add server capacity. For more information, see Chapter 6, "Planning for Reliability and High Availability."
Hacker attacks or viruses	Add firewalls to your site architecture. For more information, see the "Security Requirements" section in this chapter.
Power outages, fire, flood, lightning, and so on	Back up your system regularly and store backups in a secure, off-site location. For more information, see Chapter 6, "Planning for Reliability and High Availability."

You should include this type of risk and mitigation assessment in your Project Goals and Requirements document, using risks that are specific to your project. You must determine which risks you are willing accept and which risks you will take specific actions to reduce or eliminate. You can handle risks in a number of different ways, including the following:

• Accept the risk, with no investment of effort or cost. You might want to accept a risk when the cost of mitigating it exceeds your exposure or when your exposure is acceptable.

• Transfer the risk to someone else, or agree to share the risk, if a customer or trading partner is better able to handle it without undue strain.

• Reduce the loss associated with a risk whenever possible. For example, keep a backup local area network (LAN) operational during the deployment of a new network, or provide free training to customers who would otherwise not be trained.

If you encounter significant risks that you cannot mitigate, or risks for which countermeasures are unreliable, you might need to establish and execute contingency plans. When you finish a project, be sure to capture the lessons you learned during the project so that you know what risks to watch for in future projects.

Developing a Conceptual Design

The next step in developing your Project Goals and Requirements document is to analyze and define business processes and data to support your vision statement. You use this information to create a conceptual design that integrates the development of your Commerce Server site with site testing and integration. The following table describes the information that a conceptual design should include.

Section	Describes
Business process diagram(s)	The flow of business processes associated with your proposed site, showing the interrelationship of business processes and functions, including data flows between processes and external sources or destinations
Business data model	Data entities, attributes, relationships, and business rules
Process/location matrix	The physical locations where business processes are performed (if performed at more than one location)
Data flow diagram	The flow of data between processes (if not described in enough detail in the business process diagram)
Physical conceptual design picture	A graphic representation of your applications, interfaces, databases, and hardware platforms

Defining Requirements

It is important to clearly define the following types of requirements in your Project Goals and Requirements document. Your technical team will then use this information to create the functional specification.

Type of requirement	Describes
Business	The business purpose for developing your site
System integration	Requirements for integrating Commerce Server with other software
Security	The type(s) and levels of security you need
Site architecture	Hardware configuration and location, and hardware scalability and availability requirements
Performance and capacity	Requirements for system performance and capacity, the amount of traffic the site must be able to process, and the amount of anticipated growth
System administration	The infrastructure for ongoing management of Commerce Server and other software
International	Requirements to provide for an international audience, if any

Business Requirements

Business requirements describe the business purposes for developing the site, such as the following:

• Sales goals

• Product offerings

• Customers

• Suppliers

Business requirements also describe how you expect the new site to change your current manner of doing business. It is important to understand what you want your site to do and what functions it must perform before you begin development, so that the Development phase can be as efficient, cost-effective, and successful as possible. Your business requirements should include answers to the following questions, among others:

• How do we currently do business?

• What business problem(s) are we trying to solve with this project?

• What are our goals for return on investment with the new site?

• What are our goals for customer relationships?

• What are our goals for supplier relationships?

• What are our goals for each phase (Plan-Develop-Deploy-Manage) of the project?

• Will there be subsequent projects after this particular deployment?

• What technical issues must we address for each phase of the project?

• What new organizational processes do we have to develop if the project is to be successful? What changes do we have to make to current organizational processes? (For example, do we need additional staff to develop or run the system? What training do we need to do when the new system is implemented?)

• What existing processes must be incorporated into the new site?

System Integration Requirements

During the planning process, you need to assess your existing systems and data to determine the most effective methods of integrating them with or converting them to Commerce Server. In addition, you need to plan how to integrate the various subsystems of your e-commerce business. The following table lists some of the questions that you need to answer when you plan for system integration.

Planning question	Recommendation
Should we integrate existing databases and database servers that contain data, such as catalogs and user profiles?	If you plan to maintain separate data sources for your offline and online businesses, establish a system for synchronizing the data. Consider integrating Microsoft Host Integration Server 2000 and Microsoft Application Center 2000 into your system design.
Should we integrate our existing order processing, payment transaction, inventory management, and order fulfillment systems with Commerce Server?	If you plan to integrate these systems, develop Component Object Model (COM) objects to connect them to Commerce Server. Consider incorporating Microsoft BizTalk Server 2000 into your system design.
Do we need to integrate Enterprise Resource Planning (ERP) systems with suppliers and trading partners?	If you plan to integrate ERP systems, you should incorporate BizTalk Server into your system design.
What are our requirements for converting data?	Convert your data from its existing format to a format you can use with Commerce Server. For example, if you have catalog data in a tab-delimited format, you will need to convert it to Extensible Markup Language (XML) or comma-separated value (.csv) file format before importing it into the Product Catalog System.
How much custom development do we have to do?	Although Commerce Server is a full-featured product, it also provides many ways for you to customize those features to suit your business requirements. Examine the features list carefully and read the product documentation before you plan to do custom development.
If we do custom development, should we do it in-house or work with a software development vendor?	Review the information about Microsoft Solution Providers and Partners at https://microsoft.com/commerce .

Security Requirements

Security means managing risks by providing adequate protection for the confidentiality, privacy, integrity, and availability of information, and it is essential to the success of any e-commerce site. Because e-commerce sites handle monetary transactions over the Internet, most sites implement a very high level of security.

To plan security for a Commerce Server site, you must plan how to combat security threats for each feature deployed on your site, selecting the policies and tools to accomplish the level of security you want. You need to configure Secure Sockets Layer (SSL) so that certain pages, such as pages that request credit card information, are served through SSL. To set this up, you need to get a server certificate and configure Microsoft Internet Information Services (IIS) 5.0 to use SSL. For more information about configuring IIS, see https://www.microsoft.com .

You can also specify a secure host name for each Commerce Server application in the Microsoft Management Console (MMC). The AuthManager object uses the secure host name to create links to secure pages. The links can lead to a different Commerce Server application or to a secure section of the same application.

To minimize the probability of a security breach, you must be able to:

• Lock down the site by controlling access to files, pages, and applications with access control lists (ACLs) on files that use the NTFS file system (NTFS).

• Control access to read/run script/write access on various folders defined in your site for IIS security.

• Authenticate site visitors.

When you plan security for your site, you should answer the following questions, among others:

• What are our security risks?

• How severe are those risks?

• How should we structure the site to address security risks?

• What do we want to be secure (user profiles, credit card transactions, Commerce Server Business Desk, catalogs, Active Server Pages (ASP) pages, databases, and so on)?

• Where should we store backups?

• How should we manage security on our site?

• Who should be allowed access to the Web site?

• Who should be allowed access to Business Desk?

• How should we react to a security breach?

• What should we do if our site is forced offline?

You should plan for site security from the beginning and design the site with security in mind. Use the severity levels listed in the following table when you consider the severity of security risks to your site.

Severity of risk	Environment
Low	Stand-alone server in a room with locked doors
Medium	Corporate desktop with intranet connection
High	Anything connected to the Internet
Very high	Monetary transactions conducted on the Internet
Extremely high	Transactions that impact people's lives and privacy (such as medical records and 911 calls) conducted on the Internet

To assess threats to your site, do the following:

1. List the environments (operating systems, networks, and so on) on which each secure item is developed, transmitted, processed, or stored, and describe how they affect your site.

2. List the types of threats to each environment.

3. Measure the risk for each threat, using the following formula:

   Risk = Damage potential / Probability 
   

   Damage potential: 1 = little damage potential, 10 = massive damage potential

   Probability of threat occurring: 1 = high probability, 10 = low probability

4. Prioritize the threats in order of likelihood and potential damage, and then define mitigating security elements for each threat, balancing the relative costs of implementing additional security versus the business costs of security breaches.

5. Plan how to counter the threats.

A typical e-commerce site architecture can contain multiple security domains, in which you place systems with different security needs. Each domain must be protected by a network filter or firewall. (A firewall is a security checkpoint that separates an intranet from the Internet. Only specific data can pass through a firewall.) The three most common security domains are:

• The Internet.

• A DMZ (derived from the military term demilitarized zone) containing the Web servers.

• A secure network on which content is created or staged and secure data is managed and stored. For example, the network on which you develop new ASP pages and then test them before deploying them in your production environment is a secure network.

Consider the following firewall configurations when you plan how to deploy your site:

• Single-firewall solution

• Two-firewall solution

• Three-firewall solution

Single-Firewall Solution

A single-firewall solution can consist of a firewall with three interfaces acting as gateways for three separate networks. In a single-firewall solution, the firewall acts as a host to the DMZ, Internet, and corporate intranet. Figure 4.3 shows an example of a single-firewall solution.

 

Figure 4.3 Single-firewall solution

Advantages 

• The DMZ is separated physically from other networks, thereby stopping any possible intrusions into the DMZ. If someone is able to exploit any publicly accessible server, they still don't have access directly to the intranet.

• There is only one firewall to purchase and manage.

• The intranet isn't dependent on the DMZ to function. If the DMZ has network problems, the intranet doesn't necessarily lose connectivity.

Disadvantages 

• SQL Servers are not separated from IIS servers. Hypertext Transfer Protocol (HTTP) and Hypertext Transfer Protocol Secure (HTTPS) are the only protocols allowed from the external network to the DMZ; however, any vulnerability found on the IIS server will jeopardize all of the other servers on the DMZ.

• Communications between SQL Servers and IIS servers still need further security because they are traveling unprotected in the DMZ.

• Some firewall vendors might not support three interfaces.

Two-Firewall Solution

The two-firewall solution is a solution in which a second firewall is placed off of the DMZ network to separate the external DMZ environment and the SQL Servers that it accesses. Creating a staging area also separates your production environment from your development environment. Figure 4.4 shows an example of a two-firewall solution.

 

Figure 4.4 Two-firewall solution 

Advantages 

• You can use a production management network to separate the intranet from the servers and users who run the externally visible DMZ. All of the servers on the DMZ and the SQL Servers are managed by a separate group of users and servers on a different network. This way, the intranet becomes much more difficult for a hacker to access.

• A firewall protects the back-end database servers from vulnerabilities that are not dependent on the relationship between IIS servers and SQL Servers. Such vulnerabilities can result in denial-of-service attacks.

• You minimize the number of computers accessible directly through the Internet by adding two firewalls, thereby making it more difficult to disrupt or abuse the database servers and the Business Desk server.

• Business Desk does not have to run over HTTPS, because the client and server are on the same network.

• Communication between Business Desk and the SQL Servers does not have to be encrypted because the communication never goes over a public wire.

• You can control "spoofing" with the firewalls. (Spoofing is the practice of impersonating another person or computer, usually by providing a false e-mail name, URL, or IP address.) For example, you can tell a server to list only SQL Server requests from one specific Internet Protocol (IP) address. Because both connections are controlled with a firewall, these addresses cannot be spoofed.

• The DMZ is separated physically from other networks, thereby stopping any possible intrusions to the DMZ. If someone is able to exploit any publicly accessible server, they still don't have access directly to the corporate LAN.

• The intranet isn't dependent on the DMZ to function. If the DMZ has network problems, the intranet doesn't necessarily lose connectivity.

Disadvantages 

• It is more difficult and costly to maintain two firewalls with different configurations than it is to manage a single firewall.

• Communications between SQL Servers and IIS servers still need further security, because they are traveling unprotected in the DMZ.

• Some firewall vendors might not support three interfaces.

Three-Firewall Solution

The three-firewall solution features two or three firewalls behind one another to create a DMZ that shares bandwidth with the intranet. Figure 4.5 shows an example of a three-firewall solution.

 

Figure 4.5 Three-firewall solution

Advantages 

• The DMZ is separated physically from other networks, thereby stopping any possible intrusions to the DMZ. If someone is able to exploit any publicly accessible server, they still don't have access directly to the intranet.

• You can control spoofing with the firewalls. For example, you can tell a server to list only SQL Server requests from one specific IP address. Because both connections are controlled with a firewall, these addresses cannot be spoofed.

• A layer of protection protects the back-end database servers from vulnerabilities not dependent on the relationship between IIS servers and SQL Servers. Such vulnerabilities can result in denial-of-service attacks.

• You minimize the number of computers accessible directly through the Internet by adding three firewalls, thereby making it more difficult to disrupt or abuse the database servers and the Business Desk server.

Disadvantages 

• It is more difficult and costly to configure and maintain three firewalls with different configurations than it is to maintain single- or two-firewall configurations.

• Communications between SQL Servers and IIS servers still need further security, because they are traveling unprotected in the DMZ.

• Connection to the Internet from intranets can be disrupted if certain types of denial-of-service attacks occur in either the DMZ or SQL Server networks.

• Any traffic allowed between the intranet and the Internet is also allowed between the DMZ and the Internet and between the SQL Servers and the Internet. Security ramifications depend on which protocols are allowed by the default security policy of the user.

Be sure to include the following elements in your security planning:

• One firewall between your Data Warehouse, Administration database, and other data stores, and your Business Desk, and another firewall between your Business Desk and Web servers

• Intrusion detection tools

• Ongoing site monitoring

• Strong passwords for site visitors

• Aggressive time-outs

• Method(s) for screening all user input, including parsing for expected user input

• Network architecture to support security requirements, including firewalls, routers, and proxy servers

• Windows 2000 security settings, including authentication methods, disabling of unneeded services, security design of groups and users, NTFS permissions, privileges, and auditing

• IIS security settings, including IP address grant and deny settings, application read, write, and execute permissions, authentication methods, and use of secure communications (such as SSL, HTTPS, and certificates)

• SQL Server security settings to restrict access to Commerce Server databases, especially settings to restrict access to the Administration database, which contains the connection strings and passwords for all Commerce Server databases

• CS Authentication resource properties

• Access control for any data stores that will be shared by intranets and the Internet

• Coding practices for secure sites

• Administrative security policies to protect the e-commerce site, such as password policies, monitoring, and physical control of servers

You should also do the following:

• Protect your domain controllers behind a firewall. Don't put domain controllers on the Internet.

• Create contingency plans, such as setting up redundant hardware, in case the site is forced offline.

For more information about security requirements, see Chapter 6, "Planning for Reliability and High Availability."

Site Architecture Requirements

Your site architecture is the number and configuration of computers that make up your site, including the operating systems and application software installed on each one. You can run a small Commerce Server site (1,000 transactions a day) on one computer with 256 MB of RAM. However, it is better to run Commerce Server on a minimum of three computers: one for your Web server, one for SQL Server, and one for Business Desk site management. Many e-commerce sites start small and grow exponentially with demand, so it is important to plan a solid architecture that meets current and near-term demand, and that will also scale easily.

In addition to the hardware for running your operating environment, you need to plan for hardware to run the environments listed in the following table, as well.

Environment	Function
Development environment	Develop changes to your site.
Test/staging environment	Test all software changes to the site before putting them into production. It is important to maintain a separate site for testing changes to make sure everything works before you install new software in your production environment. The test/staging environment should be an exact duplicate of your production environment.
Redundant operating environment (optional)	Maintain operations in case of malfunctions in your production environment. If it is critical for your site to keep operating at all times, you should consider building a redundant operating environment that can be brought into use immediately when needed. (For information about other options for increasing site availability, see Chapter 6, "Planning for Reliability and High Availability.")

Performance and Capacity Requirements

Performance and capacity requirements are closely linked because performance planning and capacity planning go hand-in-hand. However, each addresses a different perspective. Performance planning addresses the technical aspects of the site, focusing on performance metrics such as ASP page throughput and ASP latency. Capacity planning addresses the business perspective, focusing on maximizing the number of users that a site can handle. For information about maximizing the performance and capacity of an existing site, see Chapter 19, "Maximizing Performance."

Performance

It can be difficult to predict how variables in site design, coding practices, user behavior, and site architecture will combine to affect site performance, so it is important to plan and test the performance and capacity of your site before going into production. If you are upgrading an existing site, you can use site data as a basis for planning the new site. If you are creating a new site, you can use the guidelines provided in this book to set up a test site, on which you can then load, test, and optimize your site before "going live." When defining performance requirements for your site, you need to answer the following questions, among others:

• What are our performance goals for this solution?

• What is the size of the content managed in databases or on Web pages?

• What is the maximum delay (latency) for returning the bulk of the Web pages?

• What are our criteria for measuring the success of our site, in terms of page latency minimums and necessary throughput to survive at peak or stress levels?

• How many servers do we need? How should they be configured?

• How should we balance the load across all of our servers?

Performance plans should include the following:

• A list of items to measure, such as ASP throughput and ASP latency. Select factors that closely match your goals for user experience. For example, if your goal is for users to be able to browse through your catalog quickly, measure the speed at which a catalog browse request is returned.

• Tools and resources for analyzing performance.

One of the most useful tools for analyzing performance on an existing site is transaction cost analysis (TCA), which is a methodology for estimating the cost of each resource as a function of usage profiles, service mixes, or hardware configurations. For more information about TCA, see Chapter 19, "Maximizing Performance."

Capacity

Capacity planning addresses the business perspective of a site, focusing on maximum user capacity. Capacity planning enables you to make sure that your site delivers quality content to users at a rapid speed. If capacity planning is measured incorrectly, users might choose to go elsewhere to find better service, quality, and speed.

When defining capacity requirements, you should answer the following questions, among others:

• What are the typical usage profiles of the users we are targeting with this site?

• How many users do we expect to visit the site each hour and each day? Will those numbers be different on weekends?

• How many users do we expect to visit the site during peak seasons or special promotions?

• How frequently do we expect users to interact with the site? (How many times will they access our home page, and over what span of time, or how many catalog searches do we expect users to make each time they visit our site?)

• How many users need to be supported both near- and long-term?

• At what rate do we expect to grow?

You should review site capacity regularly, to be sure that the infrastructure of your site can maintain and deliver services at acceptable performance levels as you grow and as site content becomes more complex. When you plan site capacity, you need to determine capacity separately for each Commerce Server feature that you plan to use.

Predicting capacity is a little more complex than predicting performance. Before you can predict maximum capacity, you first need to profile expected (or actual) user behavior, and then combine that information with your performance metrics to calculate capacity. User behavior varies from site to site, depending on the richness of the shopping experience (page design, site design, and response time), as well as the types of products being sold and the breadth of the product line. One site might support 1,000 users, while another site with identical hardware might support only 200 users, due to differences in user behavior.

You can project user behavior on your site by providing answers to questions that identify which user operations are to be performed and how often you expect them to be performed over a given period of time. For example, you can design a usage profile to answer the following types of questions:

• What will users do after connecting to the site? Will they view only a few pages or will they browse the site extensively?

• When users browse product offerings, how often will they make a purchase?

Creating a usage profile is the first step in determining site capacity. The key components of a usage profile are:

• The projected length of an average user session.

• The total number of operations performed by the average user during a session.

• A list of commonly used user operations.

• The frequency with which each operation is performed during a session.

In a typical site, for example, the following transactions might account for 10 percent of the types of page requests, but 90 percent of the site traffic:

• Add item and checkout

• Add item and delete

• Browse

• Check zip code

• Default (home page)

• Log in

• Register

• Search (Bad)

• Search (Good)

• View cart

Determine how you expect users to connect to your site and the expected load. Use this usage profile in your testing environment, and then confirm that the profiles are correct when you have collected usage information in the Data Warehouse. For more information about creating usage profiles, see Chapter 19, "Maximizing Performance."

Performance and Capacity Considerations for Site Architecture

You use performance and capacity data to determine the following requirements:

• Number of servers and their roles, including which services, resources, and files each server is to provide; efficient co-location and distribution of services

• Server size (processor, memory, and storage requirements) for each type of server

• Network bandwidth and hardware

• Site architecture, to gain maximum performance from existing servers (For more information about architecting a site to increase its performance, see Chapter 5, "Planning for Scalability.")

The following table describes some diagrams that are helpful for visualizing site architecture.

Diagram	Description
Hardware profile	A description of, and budget for, the hardware needed to implement a site, including diagrams of the expected deployment configuration. This deployment configuration should include the servers on which each software component will reside. Be sure to include network hardware in this description (routers, firewalls, and so on).
Service-to-service architecture	Network diagrams to describe the bandwidth necessary to support the planned throughput, and event-sequence charts (such as the example shown in Figure 4.6) to map the flow of requests through the various systems, so that you can see potential bottlenecks. Generating these diagrams early in the Planning phase can highlight unforeseen problems and bottlenecks.
Server configuration matrix	A network diagram of server roles, data roles, and client roles.

Figure 4.6 shows the type of event-sequence chart you might create to map the flow of requests through your site.

 

Figure 4.6 Event-sequence chart

Determining User Capacity

You can determine the capacity requirements of your site using the number of expected or actual visitors to your site during a period of time and comparing it with the capacity of the hardware.

For example, if the site receives 500,000 visitors per day at an average session time of 11 minutes, there are an average of 3,800 concurrent users at any given time. The equation is as follows:

(500,000 / (24 hours * 60 minutes / 11 minutes per session) = 3,800 users

Of course, this does not mean that there will be 3,800 site visitors at any particular time. There might be times when site traffic peaks at a much higher figure. One of the important principles of capacity planning is to use peak activity, rather than average activity, as a baseline. As a rule of thumb, you can account for usage spikes and peaks by multiplying the average number of concurrent users by two (although this multiplier can differ, depending on the nature of your site).

In the previous example, this calculation yields a figure of 7,600 concurrent users at peak periods. If your site experiences peak traffic that is more than twice the average, consider this when you determine where to set your baseline.

If you had already determined the server CPU capacity for your site to be 1,350 users, you would then divide 1,350 into 7,600 to determine how many servers you need to handle peak traffic, as follows:

7,600 concurrent users / 1,350 users per server (2 processor) = 6 servers (running Windows 2000 with 2 x 400-MHz processors)

At times of normal use, the load on the six servers would be lower:

3,800 concurrent users / 6 servers = 634 users per server

This means that your site would be operating at 50 percent of site capacity. Knowing your site capacity is very important, especially for sites that experience usage spikes.

Planning Site Topology

Each site has unique capacity requirements that can be affected by variables such as available hardware and budget, available physical space for servers, and the amount of time your company can afford for the site to be offline. Such requirements directly affect the design and construction of the site's physical infrastructure, the site topology. For examples of site topologies, see figures 4.3, 4.4, and 4.5 in the previous Security Requirements section.

The following table lists some of the questions that you need to answer when you plan how to configure site topology.

Planning question	Recommendation
What server operations (like backing up files and content replication) can influence site capacity?	Because TCA measurements don't include operations such as maintenance and system management, you should decide what capacity you need for those activities in addition to the capacity required to handle Web traffic.
How often do we expect usage spikes to occur? How important is it to perform well during such spikes?	The general rule is to plan enough capacity for twice the average number of concurrent users. If you anticipate significant usage spikes that exceed this baseline, plan for surplus CPU, disk, memory, and network capacity. Remember to take future growth into consideration, as well as the possibility of content that is more complex.
How important is it to be operational 100 percent of the time? How often will servers be offline for maintenance?	If 100 percent site availability is critical, plan for system redundancy. Duplicate critical resources and eliminate "single point of failure" areas.
When will we do capacity planning again? What growth do we expect? When should we upgrade the site hardware again? How will content complexity change?	Over time, the average number of concurrent users on a site rises or falls, the content and content complexity changes, and the typical user profile changes. Each of these factors can have a big impact on a site's capacity. Take change and growth into account, and review your capacity plans regularly or whenever these factors change sufficiently enough to impact site capacity.

Scalability

Your initial site design should take future expansion into account. A well-planned site can be cost-effectively expanded, or scaled, to accommodate increased site traffic while maintaining performance. The architecture of e-commerce sites is generally divided into two tiers: front-end Web servers, and back-end servers on which database software, data, and operations are located.

You typically scale the front end by scaling horizontally—adding additional, identical Web servers. The Web servers are joined into a farm or cluster, and load balancing is used to distribute user requests evenly across the available servers.

You typically scale the back end first by scaling vertically—upgrading the server and adding mass storage. Then, you can also divide the data by function among two or more servers. For example, the Data Warehouse can be placed on one server and the registered user database on another. With Commerce Server, you can divide functions onto different servers during setup, or do it later using Commerce Server Manager.

Using Commerce Server, you can partition the Commerce Server databases (the databases containing catalogs, campaigns, and so on), and you can add SQL Server databases to the Data Warehouse. Commerce Server also makes it easy to add Web servers, using Commerce Server Site Packager. You can manage them from one central location.

Issues to consider when planning for scalability include:

• Designing a multi-tier architecture, even if your initial site traffic is low.

• Planning a scaling path for each type of server, each network connection, and each Commerce Server feature, in which you define how you will scale the site when certain thresholds (such as number of concurrent users, memory usage, or disk usage) are reached.

For more information about ways to scale a site's architecture, see Chapter 5, "Planning for Scalability."

Availability

Availability is a measure of fault tolerance for a computer, cluster, or system, and its programs. The measure takes into account both the mean time between failures (MTBF) and the mean time to recovery (MTTR), and includes downtime for both planned and unplanned events. Many e-commerce sites are mission-critical, so they should be designed to be highly available, which means operating at an acceptable service level at least 99.9 percent of the time. Planning for high availability includes defining and testing hardware and software configurations, as well as operational procedures.

Front-end systems are made highly available as well as scalable by using multiple, identical servers, all offering a single address to their clients. Load balancing distributes load across the servers. Building failure detection into the load-balancing system increases service availability. In that way, a server that is no longer offering a service can be removed automatically from the load-balanced set while the remaining servers continue to offer the service.

Back-end systems are more challenging to make highly available, primarily due to the data or state they maintain. They are made highly available by using failover clustering for each partition. Failover clustering assumes that an application can resume on another computer that has been given access to the failed system's disk subsystem. Partition failover occurs when the primary node supporting requests to the partition fails and requests to the partition automatically switch to a secondary node. The secondary node must have access to the same data storage as the failed node. A duplicate e-commerce site can also increase availability by being available at a remote geographic location.

The following table lists some of the questions that you need to answer when you plan a highly available system.

Planning question	Recommendation
What level of availability do we require?	Make this decision by weighing the cost of availability against the business cost of downtime, and determining an appropriate availability level.
How should we monitor availability?	Create a process to determine whether you are meeting your availability goals.
How should we respond to disasters?	Develop a plan for recovering data in the event of a catastrophic failure of all or part of your system. Test your plan by simulating a disaster.

For more information about planning for availability, see Chapter 6, "Planning for Reliability and High Availability."

System Administration Requirements

System administration broadly refers to the infrastructure, tools, and team of site developers and system administrators needed to maintain a Commerce Server site and its services. Many Commerce Server sites are located in hosted environments (co-located with an Internet Service Provider (ISP) or a specialized hosting service), where rich Internet connectivity is available. Consequently, the management and monitoring of the systems must be done remotely. In such a divided architecture, management tasks are split between the ISP and the remote client. The ISP in this case plans the management infrastructure, and the client plans the configuration of Business Desk.

In Commerce Server, site management describes what tasks the business manager does using Business Desk. System administration describes what tasks the system administrator does using Commerce Server Manager.

When you plan your site management and system administration, you need to answer the following questions, among others:

• Who is going to use Business Desk and for what?

• How is the business manager going to communicate changes to the system administrator (such as requests for customized reports, or a request to run a direct mail job)?

• How are changes to the Web site going to be communicated to the site developer?

Issues to consider when planning a management infrastructure include:

• Placement of Commerce Server, IIS, and SQL Server MMC management computers and a determination of who will use them.

• Placement of cluster management and enterprise management computers, if used, and a determination of who will use them.

• Procedures for routine management tasks, such as content updates, hardware and software upgrades, service packs, and monitoring.

• Tools and utilities needed to manage the site.

• Remote management requirements. The business manager can use Business Desk remotely. Commerce Server Manager can be set up on an administration-only computer (a computer that does not have any other Commerce Server objects installed).

• Security monitoring.

International Requirements

If your site has an international audience, you need to plan how to handle multiple languages and currencies.

When you plan for an international audience, you need to answer the following questions, among others:

• How many currencies do we need to support? What are they?

• How many languages do we need to support? What are they?

• How will local laws affect the way we do business?

• Do we conform to local privacy policies?

• What taxes do we need to collect?

• How should we ship our products internationally?

One of the most important aspects of an international site is planning how to localize the catalog. True internationalization of a site is ideal, but many customers might be happy simply to transact business in a single currency, so long as they can read about what they are buying. There are a number of ways you can accommodate multiple languages, such as using multiple catalogs or even just adding attributes for descriptions in each language.

You need to decide whether to have one Commerce Server store with separate pipelines, catalogs, and so on, for each locale, or to have a separate Commerce Server store for each locale and try to share code between them. Separating the stores would introduce complexity in the back end of the store, with catalogs, prediction, user profiles, data warehousing, and so on.

You should consider the following requirements when you plan an international site:

• Separate content from presentation for easy translation (both for data stores and Web page design)

• Support any SQL Server sort order

• Support high-inflation currencies (where the price of an item or the basket total can become a very large number)

• Take into account variations in credit card validation methods in each country

• Consider classic internationalization/localization issues, such as:

  • Using Unicode to represent text

  • Using the correct date formats, calendars, and currency separators

  • Using appropriate colors, political terms, and so on

For more information about configuring and using the international support of Windows 2000 and the Windows 2000 MultiLanguage Version, see https://www.microsoft.com/globaldev/default.mspx .

Selecting Commerce Server Features

Part of the planning process for your Commerce Server site is to determine which Commerce Server features to use, how to configure those features, and what other Web site functionality you need. Commerce Server is composed of five tightly integrated subsystems, as well as tools you can use to administer and manage your site:

• Administration and Management Tools

• Business Analytics System

• Business Process Pipelines System

• Product Catalog System

• Profiling System

• Targeting System

Administration and Management Tools

Commerce Server provides three tools for managing and administering your installation.

Tool	Description
Commerce Server Business Desk	Hosts business management modules that you use to configure, manage, and analyze your site. For example, you can use Business Desk modules to update pricing information in your catalogs, target new advertisements to specific users, and then run reports to measure how these changes affect site productivity.
Commerce Server Manager	Manages and configures Commerce Server resources, sites, applications, and Web servers. The Microsoft Management Console (MMC), a Windows-based interface that is included in Microsoft Windows 2000, hosts Commerce Server Manager.
Commerce Server Site Packager	Packages a site and its applications and resources into a single file (package), and then moves that file to another environment. Site Packager provides a convenient way for site developers to deliver sites to their customers.

You need to make some decisions about your site to make the best use of these tools. The following table lists some of the questions that you need to answer when you plan how to administer and manage your site.

Planning question	Recommendation
Is our site aimed primarily at customers or at trading partners?	If your site is aimed at trading partners, use the Partner Service, which enables trading partners to manage their accounts.
Do we need to exchange documents with trading partners?	If so, plan to integrate BizTalk Server with your implementation.
What payment options should we support?	Make the necessary arrangements with a banking institution if you plan to support credit card processing.
What currencies do we have to support?	If you plan to localize your site, you need to decide what currencies to support.
How will business managers access Business Desk?	Access to Business Desk should be over a high-speed line.

Business Analytics System

You use the Commerce Server Data Warehouse to collect day-to-day operational data about users who visit your site: user profile data, transaction data, and click-history data. You use Business Desk to analyze the data. For example, you can identify user trends or analyze the effectiveness of a campaign, then update your site to target specific user groups, sell specific products, and so on. The following table lists some of the questions that you need to answer when you plan how to use the Business Analytics System.

Planning question	Recommendation
What data do we need to make key business decisions?	Examine the standard reports available from the Business Analytics System. If you need additional information, you can extend the reporting functionality. There are also a number of third-party software vendors who provide reporting solutions that interact with the Business Analytics System.
Who needs access to the data? How often do they need to see the reports, and how much detail do they require?	You should establish a schedule for running reports. Static reports need to be run regularly so that the data does not become outdated. The schedule for running reports should be coordinated with Data Transformation Services (DTS) tasks.
How often should we process our Web server logs?	This decision depends on the size and nature of the data you store in these logs. The less frequently you process the logs, the larger they will be. Larger log files provide a richer data set, but they also take longer to process. Determine the appropriate processing frequency in your testing environment, and then apply it to your production environment.

Business Process Pipelines System

You use pipelines to define and link together one or more stages of a business process, then run them in sequence to complete a specific task. Each stage of a pipeline contains one or more pipeline COM objects that can be configured to meet your site's requirements.

You can use the pipeline infrastructure to implement several pipeline models: the Order Processing Pipeline (OPP), the Direct Mailer Pipeline, the Content Selection Pipeline, and the Event Processing Pipeline. The following table lists a key question that you need to answer when you plan how to use the business processing pipelines.

Planning question	Recommendation
Do the pipeline components that ship with Commerce Server meet our requirements? If not, should we build our own components or purchase them from a third-party pipeline component developer?	Examine the functionality provided by Commerce Server. If the processing stages do not meet your needs, you can either extend the pipelines yourself or contact a third-party pipeline component developer to purchase pipeline components.

Product Catalog System

You use the Product Catalog System to create catalogs of products and to add and update product data. This system provides both import and export functionality, and enables you to define and modify your catalog schema. The following table lists some of the questions that you need to answer when you plan how to use the Product Catalog System.

Planning question	Recommendation
Do we have an existing product catalog database that can be used directly by our online store? If so, should we continue to maintain the old catalog, or move it over completely to the new Product Catalog System instead?	Synchronizing information in the Product Catalog System with your offline catalog requires development of custom software. Consider integrating your existing catalog system with other features of Commerce Server.
What is the best organizational schema for our catalog?	The Product Catalog System is flexible enough to accommodate a variety of schemas. If you design a new catalog, be sure to provide plenty of opportunities for expanding the schema.
Do we need to provide unique pricing to different groups of customers?	If so, create a custom catalog to which you can apply pricing rules. You should plan custom catalogs in conjunction with planning how to use the Profiling System.
Do we have particularly complex pricing schemes or other requirements beyond the functionality of the Product Catalog System?	Consider using a third-party catalog management solution. A number of catalog solution vendors have integrated their products with Commerce Server to provide additional functionality.
Do we need to exchange catalogs with our trading partners?	If so, include BizTalk Server in your deployment plan, because it provides functionality for exchanging catalogs.
What catalog data should we export to the Data Warehouse?	You should export the information you need to create the reports identified when you planned how to use the Business Analytics System.

Profiling System

In Commerce Server, you use profiles to collect and store information about the users who visit your Web site. The data that forms a profile comes from multiple data sources, such as Web log files and Commerce Server databases. You import the profile data into the Data Warehouse. You can then analyze it and use the results of your analysis to target content to groups of users. The following table lists some of the questions that you need to answer when you plan how to use the Profiling System.

Planning question	Recommendation
Which data store should we use to store profiles, and what data should we store in the profiles?	If you plan to authenticate users with their Windows 2000 security context, you need to store some profile information in Microsoft Active Directory. If you do not plan to do this, use SQL Server to store profile data.
What profile information should we export to the Data Warehouse?	You should export the information you need to create the reports identified when you planned how to use the Business Analytics System. (However, don't export personal information, such as credit card numbers or passwords.)
What information should we collect about users?	You can either collect information from users directly (explicit data) or you can use the Predictor resource to fill in the information you need (implicit data).
Are there existing user accounts that we need to transfer into the Profiling System? If so, do we need to transfer all of the attributes from the current system?	If you are transferring from Site Server 3.0 Membership Directory, use the Directory Migration Toolbox to transfer this information. Don't plan to maintain the Membership Directory after you have migrated to Commerce Server.

You can also use Active Directory as a data source for profile data. Active Directory is the directory service built into Windows 2000. You can use Active Directory to add, modify, delete, and organize your organization's business entities. For example, Windows 2000 user accounts, computer accounts, security and distribution groups, and published resources are all accessible through Active Directory.

The Profiling System can aggregate data from Active Directory and other data sources into a single business entity that you can then use in your Commerce Server implementation. For example, you can store the account number and password of a user in Active Directory and store the rest of the profile information (contact information, credit limit, preferences, and so on) in a SQL Server database. The Profiling System can then assemble data from these two data sources into a single user profile that you can use for targeting and analysis.

Active Directory is a highly robust and scalable technology; however, it is important that you design your site architecture to use it appropriately. The following table lists some questions that you need to answer to determine how you can best use Active Directory in your site design.

Planning question	Recommendation
What data should we store in Active Directory?	Store only non-volatile data in Active Directory.
What volume of data should we store in Active Directory?	You can store up to one million user accounts in a single Active Directory domain. This estimate is based on the following assumptions: One percent (10,000) of the users will be actively using the site at one time. The ratio of the number of items written to Active Directory to the number of items read from Active Directory is no more than 14 percent. If you need to accommodate more than one million users in your Active Directory store, you can assemble multiple domains, each containing one million users. If you intend to use Active Directory for larger-scale implementations, engage Microsoft Consulting Services (MCS) to assist you with planning how to do this.

Targeting System

You use the Targeting System to deliver content to one or more selected users. The Targeting System includes four distinct subsystems, which you should consider when you plan how to use the Targeting System:

• Content Selection Framework (CSF)

• Direct Mailer

• Expressions (Expression Builder, Expression Evaluator)

• Predictor resource

Content Selection Framework

The Content Selection Framework (CSF) is a framework based on the Commerce Server pipeline architecture. You use the Commerce Server Business Desk Campaigns module to create and schedule marketing campaigns (advertisements, direct mail campaigns, discount campaigns, and other promotions). You can also manage different types of campaigns for multiple customers. CSF can rank, select, and schedule any type of content. The following table lists some of the questions that you need to answer when you plan online campaigns.

Planning question	Recommendation
Do we plan to target campaigns to particular groups of users? If so, what user attributes should we target?	Use the Business Analytics System to determine common buying patterns on your site, and then incorporate this information into the Targeting System. This should be an ongoing process.
What information do we need from the Business Analytics System to make pricing decisions?	Determine your information requirements for the CSF and use this information to evaluate the reports provided by the Business Analytics System.
Should our campaigns use the Predictor resource? If so, what are the key user segments we need to target?	Collect information about usage patterns in the Data Warehouse, use the Predictor resource to identify user segments, and then use this information to update your campaigns.

Direct Mailer

Direct Mailer is a fast, scalable Windows 2000 service that you can use to send personalized e-mail messages from a Web page, or non-personalized mailings from a flat text file, to large groups of recipients. Direct Mailer can be used as a stand-alone process or integrated into the Campaigns modules in Business Desk. Direct Mailer tracks e-mails that have been sent, and clicked, enabling to you to analyze the success of a direct mail campaign. The following table lists some of the questions that you need to answer when you plan your direct mail campaigns.

Planning question	Recommendation
Who should we include in direct mailings? What rules should we use to determine the mailing list?	Use List Manager to create and manage lists of direct mail recipients. Direct Mailer uses mailing lists to create and send pieces of mail to targeted recipients in the list.
How will users tell us they want to be removed from the direct mail list?	Always include an "opt-out" choice in your direct mailings.
How often should we send direct mail?	Establish a schedule and develop a script to automate the process.
Should the direct mail be personalized? If so, what user profile information should we include in the personalization?	Personalized mail is more effective. Design your user profiles to include the attributes you want to use for your direct mail targets.

Expressions

An expression is a condition you can set up to determine, for example, whether or not content should be delivered to a particular set of customers. You use the Expression Builder to create targeting expressions for your marketing campaigns (such as "young adults = ages greater than 16, but less than 25"). You use the Expression Evaluator to create business rules for personalized ad targeting, promotions, direct mail campaigns, and content targeting, based on evaluations of the conditional expressions you created with the Expression Builder. The following table lists a key question that you need to answer when you plan how to use expressions.

Planning question	Recommendation
What experience do we want to create for our users? What business rules should we create to facilitate that experience?	Base your expressions on the personalization requirements developed for the Targeting System. For example, if you have decided to display content based on a referring Uniform Resource Locator (URL), you might create the expression Referrer equals URL.

Predictor Resource

You can use the Predictor resource both to recommend products to users online and to fill in missing properties in user profiles. Collect data on at least a few thousand users to get enough data to analyze before you deploy the Predictor resource. The following table lists some of the questions that you need to answer when you plan how to use the Predictor resource.

Planning question	Recommendation
Should we enhance our targeting and provide product recommendations to users?	Implement the Predictor resource by building models of user behavior after you have collected some initial data in your Data Warehouse.
What key user segments should we identify in order to make meaningful recommendations?	Use the Predictor resource to identify meaningful segments, and then view them with the Segment Viewer in Business Desk.
Should we use inference to augment user profile data, or should we make recommendations based only on data explicitly provided by users?	If you plan to infer user properties, use the Segment Viewer in Business Desk in conjunction with the Dependency Network view in Commerce Server Manager to focus on the key user attributes you plan to use to make predictions.

Planning for Migration

You need to plan how to migrate your present operations to the proposed new site, whether you are migrating from existing software or migrating from a completely manual system.

Issues to consider when planning for migration include:

• Migrating authentication methodologies.

• Migrating profiles, such as those for users and products.

• Migrating pipelines and order processing flow.

• Migrating catalogs.

• Migrating the User database or Membership Directory to Microsoft SQL Server or Active Directory.

• Migrating Site Vocabulary to site terms.

• Migrating data center management and site processes.

• Migrating credit card processing.

• Integrating with order processing, inventory, or other existing systems.