chapter 6 managing e-commerce web site development

Chapter 6: Managing E-Commerce Web Site Development “There is no course of life so weak and sottish as that which is managed by order, method, and discipline.” —Michel Eyquem de Montaigne (1533–1592) Overview Electronic commerce is quickly shaping up to be the way business will be conducted in the future. This chapter takes a look at how an e-commerce Web site is managed as it is being developed. In other words, this chapter is not necessarily about electronic commerce in general. It is actually an exercise in building and managing a business-to-consumer electronic commerce site. In addition, this chapter does not discuss management concepts or other tools available to implement e-commerce, but focuses exclusively on Web site servers. The names “site server” or “commerce server” are used interchangeably throughout this chapter. It is assumed that there exists a set of requirements that the final site should adhere to and follow with the development of the site itself. Note Please check all information or take professional advice before embarking on an electronic commerce project. Web Site Server A Web site server is a comprehensive Internet commerce server an organization can use to build an e-commerce architecture (see sidebar, “Building an E-Commerce Architecture”) and monitor/manage business sites on the Web. By providing a comprehensive set of server components, management tools, and sample sites, a Web site server significantly reduces development time and costs for business-to-consumer applications. Building an E-Commerce Architecture E-commerce continues to hold tremendous profit potential for many companies. It still offers faster response to customer needs, reduced operating costs, and increased cooperation among customers and trading partners—if it is done right. This means not bringing an e-commerce offering to market before planning a workable architecture. Now, more than ever, companies must thoroughly plan and carefully build their e-commerce architecture before the first customer ever comes on board. That’s because capital, time, and resources are scarcer today; margins for error are slimmer; and shareholders are less in the mood to support initiatives that don’t work out of the gates. As a corollary, chief information officers (CIOs) frequently have to be the voice of reason in their companies to ensure that a truly robust, reliable system is built. ClOs may be the company’s only executive-level people who understand the architectural firepower needed to build and run a scalable, reliable e-commerce backbone. Only you may be able to explain to your CEO why you need an integration layer or how your architecture plan is the best among competing models in the market. And, only you may be able to explain how much time it takes to build the architecture correctly. Putting the cart before the horse has never been a wise move, but it was briefly accepted as a viable business strategy in e-commerce initiatives. In 2001, a company could tout its e-commerce offering, get customers, and then worry whether it had the scalability, reliability, and security needed to support business. But that’s over. With the first casualties of the e-commerce revolution fresh in mind, potential users of your e-commerce system want to know that you can deliver. ClOs can help their companies by insisting that they take the following steps: 1. Plan: The architecture is the structure of the e-commerce system and will determine what the company can and cannot do, both now and in the future. Therefore, it’s critical for the system’s software engineers to develop an architecture blueprint up front. The blueprint should include the highest-level design of the business solution and processes; highest-level technical design and lower-level designs; and information on any relevant special structures, interfaces, or algorithms. 2. Plan for the “ilities”: When well-planned and well-built, the architecture will deliver on all of the key “ilities”—such as scalability, reliability, availability, and serviceability. But, in their hurry to get to market, far too many companies short themselves on the necessary components and vendor partners. CIOs can insist on components from best-in-class technology providers and consult development firms that have implemented applications within a broad range of architectural schemas. 3. Plan for integration: The technology infrastructure must allow you to integrate customers’ legacy systems, third-party vendors, and applications to come in the future. For example, insurance companies have extensive legacy systems and various business partners that must be accommodated. For example, DriveLogic, the e-commerce arm of CCC Information Services and a leading provider of technology solutions to over 460 of the nation’s top insurers, has implemented an architecture that will be able to communicate with all of these systems. It allows insurers to leverage existing technology and data—a considerable asset—and accommodates insurer business partners and other technology vendors as well. 4. Make good vendor choices: A robust system calls for the best vendor partners. Like a house built with cheap materials, architecture pieced together with Iow-rent components and vendors won’t wear well— and, may jeopardize your company’s reputation for years to come. Today, it’s more critical than ever to get the e-commerce strategy right in the preplanning stages, well before you ever bring the offering to market. To be a leader, and avoid the mistakes of the past few years, a company must build it right from the start [1] . By using a set of objects, tools, wizards, and sample sites, one can add Internet commerce capabilities to an existing Web site or can quickly and easily create a new electronic commerce site. A commerce server usually supports business-to-consumer sites as well as business-to-business and corporate purchasing sites. Business-to-Consumer (B2C) Sites These B2C sites sell products to the consumer through the Web. A commerce server should include support for advertising, promotions, cross-sells, secure payment, order processing, and consumer wallets. Business-to-Business (B2B) Sites A B2B site is the other hot application for e-commerce, as a replacement for EDI. A commerce server provides features for building business-to-business sites, such as support for purchase orders, order approval routing, and the secure exchange of business information between trading partners. [1] Beattie, Jim, “When Building E-Commerce Architecture: Don’t Put the Cart Before the Horse,” Copyright ©2003 Cognizant Technology Solutions, Cognizant Technology Solutions, 500 Glenpointe Centre West, Teaneck, New Jersey 07666, 2003 Developing a Commerce Site Developing a commerce site is similar to developing an application, and a structured approach is recommended. This part of the chapter discusses a development methodology for the commerce site. An approach with the following stages is recommended here:  Scope  Prototype  Design  Implementation  Testing  Deployment [3] Scope The Scope stage involves the following activities:  Researching the business requirements  Projecting the infrastructure needs of the solution  Establishing the overall technical architecture of the solution  Performing an initial analysis of the security, performance, maintainability, and integration issues  Specifying a schedule for development and implementation of the solution [3] Prototype The Prototype stage involves building a basic layout of the site so as to get a taste of what the site will look like. The prototype is essentially the foundation for the final site and can be modified according to the customer’s feedback. Design The Design stage involves developing the logical design. It also involves designing the user interface and deriving the physical design. Implementation The Implementation stage involves translating the design into the actual site. This can be in the form of changes and updates to the prototype. The key tasks are creating the user interface, developing custom components for the order processing pipelines, if needed, and implementing the database according to the design. Testing and Deployment The site should be tested before deployment. Among other things, the site should be tested for security, user interface, performance, and ease-of-use. Furthermore, the site developed should be deployed. [3] Ganesh, Arvind, “Enterprise Application Development and Commerce Site Server,” Copyright ©2003 California Software Labs, Ltd., California Software Labs, Ltd., 6800 Koll Center Parkway, Suite 100, Pleasanton, CA 94566, 2003. Building the Site A site manager should be able to connect to the manager’s pages and build the site by running the wizard. This generates all the files and database tables, including product pages, basic layout, shipping and handling, tax, and payment. Furthermore, this builds the actual store that will exist on top of the site foundation. You should run the wizard and follow the instructions displayed on the screen. Some points of interest when building the site are as follows: 1. A locale step defines the default locale to be used in your store. This drives the configuration of the default tax calculation component as well as the format used to display currency and other localized variables. 2. Price promotions allow you to offer promotions, such as discounts based on dollars spent, percentage discounts, or a two-for-one promotion. Cross-sell promotions allow the site to offer a related product when a shopper selects a particular product. 3. With a features step, you can choose if and when you want shoppers to register at your site and whether you want to maintain this shopper information in the site’s database. 4. A product attribute type step is based on the type of products that the site intends to offer. With static attributes, all products have the same attributes. 5. Dynamic attributes allow the site to sell products that might differ in attributes, for example, one item may be offered in multiple colors, but not list the manufacturer’s name, and another item, such as a shirt, might have varied sizes, neck size, sleeve length, and color. 6. An order history step offers the option for the site to store a shopper’s order history and receipt information [4] . This information is useful to customers who may want to look up existing orders. In addition, it can provide a source for integrating into an existing customer service application [3] . After running the wizard, your sample site is now ready and open for shopping. Now, let’s take a look at how the wizard-generated site meets many of the stated requirements right “out of the box.” With reference to the list of requirements given earlier, the site meets the following requirements at this stage: 1, 2.b, 3, 4.a, 8, 9, and 10. The site you have just built can be used as a prototype after implementing the initial user interface (UI). The Design stage is next. Design The Design stage involves coming up with the overall structure of the site. This task would be mammoth if it were not made easier by the wizard because it automatically generates the basic structure of a commerce site with features such as a shopping cart, shopper ID, order ID, and so on. To build the design for your site, you have to design it around the existing commerce site design. There are essentially three aspects to site design in a commerce server: designing the database, the order form, and an order processing pipeline (OPP). A commerce server site populates its pages with data obtained dynamically from its database. The database holds all the data related to the site—data related to the products and shoppers. The site performance and reliability is influenced by the database design. An order form object provides storage for customer and purchase information. A commerce server site uses the order form object to store the items that a customer has placed in the basket, to store bill-to, ship-to, and receipt information. The OPP is a collection of components that encapsulates the processing that is performed on the order form. Each component in the OPP has its own distinct function that it performs on the order form. Because the order form is of limited scope, the design should focus on a single example of each of the different design aspects. At the end of the Design stage, you should be clear about what is to be done in the Implementation stage. Database Design Central to the design of the site is the design of the site database. Much of the database schema required for a commerce site is automatically generated by the wizard. However, if you already have a product database in place, and you want the commerce server site to use it, you can select a sample site whose product schema most closely matches the existing database. You can use the wizard to copy that sample site, and then modify the queries as appropriate for your database. In the sample sites, database queries that are used to display information (such as product descriptions and properties) on the page are defined in the ASP file for that page. So, to accommodate a different product schema, one need only modify the query as needed and create a combination of HTML and scripting to display the product information on the page. Note For more information on ASP, see http://www.activeserverpages.com. In the case of your sample site, the need to modify the wizard-generated database schema arises because of the following previously listed requirement: 2.a—the product catalog can have products from various vendors. This requirement introduces a new entity into the schema—the vendor or manufacturer. This leads to a new relationship between the products table and the vendor table. When translated into physical design, the entity maps to a new table. A new table to hold vendor attributes is created. The relationship between products and a vendor is a many-to-one relationship. This maps to a new column in the products table that holds the Vendor ID. In general, a fair bit of denormalization is recommended because it can result in significant performance gains. Database queries should be kept to a minimum to increase speed. Order Form Values An order form object is a commerce server dictionary object. The order form object serves as working storage for order form data being collected or processed (the shopping basket). An order form object is defined internally as a structured group of dictionary objects, and includes the methods required to add items, clear items, and clear the entire order form itself. Commerce server sites use the order form object to store items that a shopper might have chosen to purchase, and to store receipt information that will hold a shopper’s order history. Some of the common values that the order form might hold are:  Shopper ID  Name  Address  Order cost information  Purchase subtotal  Tax  Shipping  Total [3] Note The order form does not directly support storage of its data on disk—instead, a database storage object (DBSO) is used to accomplish this. Now, with the preceding in mind, let’s get back to your sample site. You will need to add a few values to the order form. This is necessitated by the following requirement that was previously listed: 5. Customer should receive e- mail confirmation of his order. This functionality will be implemented by a simple mail transfer protocol (SMTP) component in the purchase pipeline. The SMTP component will require the information shown in Table 6.1 [3] . Table 6.1: SMTP component functional information and description Function Description Order. email_subject The subject for the order confirmation to be sent by e-mail to the customer Order.email_body The message body for the order confirmation to be sent by e-mail to the customer Order Processing Pipeline (OPP) The commerce server pipeline is a software infrastructure that links one or more components and runs them in sequence on the order form object. Each stage in a pipeline consists of zero or more components, and each of these components is run in sequence. A component is a Component Object Model (COM) object that is designed to perform some operation on an order form. Usually, each component has its own small task to perform. For example, a fixed shipping component checks for the right shipping method and sets the shipping cost to the appropriate value. A business-to-consumer commerce site in commerce server uses three kinds of OPPs—the product, plan, and purchase pipelines. The product pipeline is of little interest here. The plan pipeline consists of stages, which consist of components that verify the integrity of the order form. The purchase pipeline has stages and has components that accept the final purchase of an order form, write an order to database storage and finalize a receipt, and write the contents of the order form to the receipt database. Note The purchase pipeline is usually run once an order form has been run successfully through the plan pipeline, and the shopper has confirmed his desire to finalize a purchase. A commerce server should include the requisite basic pipeline components needed for a basic commerce site. When you run a wizard, it automatically creates the three OPPs required for the site—this site does not, however, feature real-time credit card validation and only includes very basic tax and shipping components. Various third- party components are available for these functions. Your sample site should use default tax and shipping components. However, you need to add a new component to handle the following previously listed requirement: 5. Customer should receive e-mail confirmation of his order. Tip Introducing the preceding functionality into the site means that you have to add the SMTP component to the purchase pipeline. [4] Vacca, John R., The Essential Guide to Storage Area Networks, Prentice Hall PTR, 2001. . Chapter 6: Managing E-Commerce Web Site Development “There is no course of life so weak and sottish as that which is. Jersey 0 766 6, 2003 Developing a Commerce Site Developing a commerce site is similar to developing an application, and a structured approach is recommended. This part of the chapter discusses a development. management tools, and sample sites, a Web site server significantly reduces development time and costs for business-to-consumer applications. Building an E-Commerce Architecture E-commerce continues