The Internet Encyclopedia (Volume 3)

P1: 61

Nyberg WL040/Bidgoli-Vol III-Ch-11 July 11, 2003 11:49 Char Count= 0

138 PROTOTYPING

careful design and reuse of generic code libraries. This is

difficult to achieve if every application the company con-

structs is a “first system.”

Your plans and your technology must be as fluid

as the changing environment in which they op-

erate. Your software, your systems, your entire

technology architecture must naturally mold and

adapt to changes without costly, time-consuming

infrastructure overhauls. Your e-business soft-

ware platform must provide a safe, yet power-

ful catalyst for ongoing innovation, increasing

customer value-add, and continuing competitive

advantage. (BEA Systems, 2002)

Architectural Complexity

A great number of e-commerce systems adopt the multi-

tier approach to software architecture; the simplest (and

most common) variation integrates a Web browser, a

Web/application server, and a back-end database. If we

think of these subsystems as residing in different archi-

tectural layers, then the boundary between each layer is

an appropriate place for security measures such as fire-

walls and virtual private network routing (Zwicky, Cooper,

& Chapman, 2000). When an e-commerce architecture is

constructed for the first time, an initial prototype can be

used to understand the complexities of integrating the var-

ious layers and their associated security protocols. A pro-

totype is also a useful vehicle for analyzing the properties

of a proposed architecture, such as

Scalability. How feasible is it to add multiple application

servers or mirror the backend database? The proposed

design can be evaluated in the context of the proto-

typing exercise, by attempting to show how multiple

servers could be added to the system for load balanc-

ing, mirroring, etc.

Robustness. How will the system react under high net-

work load and/or slow response times? What will hap-

pen if a particular networked service goes down? Once

a prototype system has been constructed, the team

can build test routines that simulate various operat-

ing conditions. It is useful to benchmark a Web ap-

plication server by simulating an increasing number

of simultaneous user accesses in order to understand

how average response time degrades under increasing

load. Simulation can also be used to test how the sys-

tem responds when certain services become unavail-

able to overload conditions (network timeout) or sys-

tem crashes.

Security. What points in the architecture are vulnerable

to attack? Can we determine them using attack simu-

lation software? If a prototype is constructed in a real-

istic operating environment (including firewalls, etc.)

then simulation can be used to identify and remedy

potential system vulnerabilities.

Integrity. Are there any circumstances where the user’s

data may be lost? To answer this question requires a

solid understanding of scalability, robustness, and se-

curity characteristics of the system and how they im-

pact the functional requirements. For each functional

requirement or supported user action (login, place or-

der, etc.) the prototype can be analyzed to determine

whether known issues with robustness and security

might impact the functional requirement. Information

gathered from prototype evaluation can be extremely

valuable in refining a system design before a full-scale

system is constructed.

Technological Risk

During product development, an organization must often

select between competing technologies (such as program-

ming languages or program libraries) to implement parts

of the product architecture or functionality. For example,

in early 1996 NetDynamics had the choice of adopting

the Java programming language or writing its own pro-

prietary language for a major release of a database inte-

gration product (Iansiti & MacCormack, 1997). At that

time Java showed promise as an emerging standard, but

was still an immature platform for large-scale develop-

ment. The engineers at NetDynamics developed a series

of prototypes in order to understand the benefits and

risks associated with each choice. The development draw-

backs of working with an immature language (which may

lack a stable, robust development tool suite) must be bal-

anced against the longer-term advantages for the applica-

tion programmer. This trade-off exists with every emerg-

ing technology, and iterative prototyping provides an ef-

fective means of evaluating the associated risks in each

case.

PROTOTYPING FOR

E-COMMERCE SYSTEMS

The preceding sections provide a motivation for proto-

typing in e-commerce system development. This section

presents the various aspects of the e-commerce software

life cycle that can benefit from prototyping, followed by

specific life-cycle models that are adapted for Web-based

applications and flexible product development on “Inter-

net time.”

Use Case Scenarios

A modern e-commerce system brings together content

and functionality on several levels. In order to understand

the overall flow of information in the system and how the

various system modules must interact, it is essential for

the engineer to analyze the different patterns of usage the

system is expected to support. A use case analysis will

identify the different users of the system (customer, in-

staller, maintainer, content provider, administrator, etc.)

as well as the functions to be provided for each user. An

initial prototype should include a skeletal implementation

or simulation of the interfaces and functionality for each

user role. Following the construction of the prototype, a

requirements review can be conducted with prospective

members of each user group to determine whether the

current understanding of the requirements (as embodied

in the prototype) is complete and correct. At the earliest

stages in development of an e-commerce site, it is useful

to build a prototype of the system’s front end (Web site,