Design for e-business

The design element of creating an e-business system involves specifying how the system should be structured.

In the two Focus on sections that follow we look at two aspects of design that are of great importance to how e-business systems are perceived by customers – security and interface design. Before that, we consider the overall architectural design of e-business systems.

Architectural design of e-business systems

The starting point for design of e-business systems is to ensure that a common architecture exists across the company in terms of hardware and software technology, applications and business processes. This goal is summarized in Figure 3.17(b).

E-business systems follow the same client-server model architecture of many business information systems created in the 1990s. For the e-business, the clients are typically employees, suppliers or customers’ desktop PCs which give the ‘front-end’ access point to e-business applications. The clients are connected to a ‘back-end’ server computer via an intranet, extranet or Internet.

In Chapters 3 and 6 we have discussed the management issues involved with selecting ‘software as a service’ (SaaS) e-business systems which are client-server systems where the client is a web browser on a computer or mobile device and the server is  located outside the organization and the application process is commonly shared with many other companies in a ‘multi-tenancy’ model.

A key design decision in client–server systems is how different tasks involved in delivering a working application to the users are distributed between client and server. The typical situation for these tasks in an e-business system is:

• Data storage. Predominantly on server. Client storage is ideally limited to cookies for identification of users and session tracking. Cookie identifiers for each system user are then related to the data for the user which is stored on a database server.
• Query processing. Predominantly on the server, although some validation can be performed on the client.
• Display. This is largely a client function.
• Application logic. Traditionally, in early PC applications this has been a client function, but for e-business systems the design aim is to maximize the application logic processing including the business rules on the server.

A typical e-business architecture uses a three-tier client–server model where the client is mainly used for display with application logic and the business rules partitioned on a server, which is the second tier, and the database server is the third tier. Since most of the processing is executed on the servers rather than the client, this architecture is sometimes referred to as a ‘thin client’, because the size of the executable program is smaller. The application server provider (ASP) described in Chapter 3 is typically based upon the three-tier model.

This is shown in Figure 11.6.

Although the three-tier model of an e-business system suggests a relatively simple architectural design, the reality is more complex. Different servers are needed which combine applications logic and database storage for different requirements. These may be physically separate servers or may be combined. Figure 11.7 shows a typical e-business architecture.
The purpose of each of the servers is as follows:

• Web server.Manages http requests from client and acts as a passive broker to other servers. Returns or serves web pages.
• Merchant server. This is the main location of the application logic and integrates the entire application by making requests to the other server components.
• Personalization server. Provides tailored content – may be part of commerce server functionality.
• Payment commerce server.Manages payment systems and secure transactions.
• Catalogue server. A document management server used to display detailed product information and technical specifications.
• CRM server. Stores information on all customer contacts.
• ERP server. Required for information on stock availability and pricing from the customer.

Will also need to be accessed for sales order processing and histories. Logistics for distribution will also be arranged through the ERP server.

It is evident that designing the method of integration between different components is not straightforward – creating a fully integrated e-business is not straightforward! As was dis­cussed in Chapter 9, the best approach to simplifying the design is to reduce the number of suppliers of components to improve the ease of data and applications integration.

Source: Dave Chaffey (2010), E-Business and E-Commerce Management: Strategy, Implementation and Practice, Prentice Hall (4th Edition).