There are two basic approaches to e-commerce patterns:

• The first approach, which is often described as a Web-up, is used to very quickly enable a Web-based buying site without any close integration with back-end systems.
• The second approach, which is often referred to as Enterprise-out, extends an existing order processing system to a new Web-based buying channel. This case includes close integration with, and reuse of, existing back-end systems.

Application patterns

From the following two Application patterns, select the one that best fits your requirements.

The Web-up Application pattern is a three-tier commerce application with deferred access to the third tier.
Select this Application pattern

Use The Web-up application pattern if you are building a new application and there is no need to interface with legacy or third-party applications or data. All of the required data is handled by the new e-business application. It does not need to share, access, or exchange data with other applications. The application implements all required functions and does not rely on functionality provided by other existing applications.

Business driver

This pattern is used by corporations that have extensive existing systems but do not want to make the modifications or interfaces necessary to use those systems directly with the new Web-based online buying channel. This pattern provides another method to submit and confirm orders, either manual or batch.

This approach provides high speed to market and low cost of implementation. The objective is classic Web-up: get the front-end shopping and buying site implemented quickly and postpone concerns about smooth interfaces to the back-end.

Key features

The Web-up application pattern allows for one or more point to point connections to back-end legacy applications or databases. In the future, the e-commerce application can be more easily integrated with existing back-end applications, for example, an ERP, or inventory management system. The examples of this application pattern typically involve some form of deferred interaction with the back-end processing of the orders.

Considerations

As your e-commerce (online buying) site becomes more successful, you will likely need to better integrate interfaces to your back-end systems. You might also demand more real time functionality, such as immediate delivery confirmation. The site will probably evolve into an Enterprise-out style implementation, as shown below.

When developing a Web-up e-commerce solution, many vendors mix the presentation and business logic layers. This type of development should be avoided. By separating the development of the presentation and business logic layers, you maximize discrete skill sets and code reuse. Failing to separate the business and presentation logic can lead to code that is hard to maintain and extend.

Example

A major retail department store wants to extend their reach to a Web sales channel. As competition is keen, time to market is crucial. Existing infrastructure includes a telephone sales channel and a back-end order processing system that runs in batch. It uses "green screen" point-of-sale terminals for online transactions. In the short-term, modifications to the backend are not feasible. The department store chooses the Web-up Application pattern because this design does not require back-end modification.

The Enterprise-out Application pattern is a three-tier commerce application with online access to the third tier (although an additional fourth decomposition tier may be added as shown)
Select this Application pattern

The Enterprise-out application pattern applies to scenarios that require integration with legacy or third-party applications. The new application is not built as a stand-alone solution but instead needs to integrate with existing applications. The integration can be achieved on a functional basis or a data basis using a transaction interface or a data interface.

When trying to integrate with an existing application, it is important to research whether the application needs to be modified and determine if the changes are allowed. If the new application is going to use existing data, you must determine if the data can be used "as is" or if the structure needs to be changed, and if so, if this modification is possible. Note that in most cases, the objective is to leave the existing applications and data unchanged.

Business driver

This pattern uses Web technology to sell goods directly to the consumer. It employs the Enterprise-out philosophy. Wherever possible, existing order management and fulfillment systems are reused. As organizations become more sophisticated in their implementation, they typically personalize the consumer's experience. For example, they might customize the user interface, using the shopper's buying patterns or stated preferences. Sometimes this customization is referred to as mass customization to a market of one, or personalization. Companies might push information to the user by prompting the shopper with information about additional purchases, specifically targeted at that individual's tastes, a technique often referred to as up-sell or cross-sell.

Key features

The Enterprise-out application pattern integrates an online buying application with existing enterprise systems. The pattern also addresses maintenance of data on that tier. Such data includes:

• Product and catalog data supporting the shopping process
• Customer-related data for personalization and registration (often duplicated in the enterprise systems on the third tier)
• Work-in-process data, such as data supporting shopping cart functionality, prior to submitting the orders for processing

In addition, the pattern provides the ability to use a form of middleware to access enterprise systems on the third tier. The middleware routes the messages to back-end systems. The middleware might decompose a request into several back-end interactions, and might serve as a broker, potentially communicating with the systems of other companies.

Finally, the pattern supports access to back-end fulfillment systems that perform functions such as inventory, order management, pricing, shipping, tax calculation, and credit processing.

At this point, the company has built an online buying site with integration to back-end systems. Some might be legacy systems that do not change (denoted by the broad black border). Some of the newly written applications are intended to support not only the Web channel but also other sales channels such as call centers.

The interactions between the shopper and the middle-tier application are synchronous during the buying process, but asynchronous confirmation messages are often sent back to the user, usually by e-mail.

Between the middle-tier and the back-end fulfillment systems, the recommended approach is online synchronous interaction. This allows immediate confirmation of important information such as the availability of inventory and delivery dates. Asynchronous (but near-time) interaction is also used in many cases. Automated and integrated batch interaction is less preferable but sometimes the only option available. While not providing immediate confirmation for the shopper, the Enterprise-out application pattern is more automated than the Web-up approach.

Considerations

The same considerations mentioned in the Web-up pattern also apply to the Enterprise-out pattern. Additionally, the following concerns need to be taken into account:

• If the developer needs to provide access to many applications on the third tier, an advanced application pattern might be more appropriate. You should consider an application pattern that exploits a hub-and-spoke architecture between the second and third tiers.
• Consider how this pattern will be deployed to avoid systems management complexity. Complexity arises when frequently updated corporate data resides on more than one tier, with the second and third tiers both within the same organization but physically distributed. For example, synchronization of backups may be cumbersome.
• If different IT organizations are developing the new application and maintaining or changing the existing systems, the development might be difficult to coordinate. Development can be especially difficult if the interfaces between the new and the existing systems are not properly defined and documented.
• The new application might require changes to existing production systems. This is always a critical task, especially when the back-end systems or third-party applications are mission critical. Building a test system for the existing applications that need to be changed is a good way to avoid production system failure, while developing and testing the new e-business application.
• Obtaining skilled resources that can change the third tier application is often a problem. Many times, these are old applications and finding someone who understands them well enough to change them might be difficult.
• The creation and management of the data on the second tier, and any required synchronization with the back-end systems, is often a major effort.
• The security of any customer data residing on the second tier is also a critical factor.

Example

A clothing retailer has a large hard-copy catalog business complete with a telephone sales channel. Customers can call telemarketers to place orders with immediate confirmation of inventory, delivery dates, and prices. The back-end order processing systems are available 24-by-7. The retailer wants to expand this business to the Web, but does not want a Web customer to have a lower level of service than a phone customer. Online integration with the order processing system will be crucial for the Web channel. The Enterprise-out Application pattern is an excellent choice for this retailer. It enables full integration with the back-end systems and a full set of customer services.