In this first part of a two-part discussion, e-business consultant Michelle
Johnston explains which factors should be taken into account in designing the
technical architecture of an e-business system.

Like this article? We recommend

Introduction

The technical architecture of an e-business system consists of two main components:

The applications architecture (see Figure
1) consists of a set of software layers—lWeb server software, Web
pages, middleware, business objects, databases, and so on—lwhich typically
can exist all on one machine or across many.

The technical infrastructure (see Figure
2) consists of the hardware components in the system—lWeb server
hardware, networks, firewalls, routers, and so on.

The design of the technical architecture to support an e-business system can
be the most important factor in determining the success or failure of that e-business
system. Typically, the technical architect will determine the applications architecture
and the technical infrastructure in the light of requirements such as availability,
performance, security, transaction integrity, resilience/robustness, reliability,
scalability, and interoperability/openness of the e-business system.

In an age in which 24x7 availability is not just preferable but necessary to
the success of an e-business system, and when a site that doesn't perform will
be rejected by business partners, getting the technical architecture right up
front is crucial.

Security/integrity of business data is necessary in order to protect competitive
advantage as well as to maintain the trust of business partners. The ability
of the e-business system to grow at the same rate as the business also makes
scalability vital. And the openness of a system provides the flexibility necessary
to take advantage of new technological advances.

To maintain flexibility, it's often sensible for the architect to design the
applications architecture (and the technical infrastructure as well) as a set
of layers, with clearly defined interfaces between the layers and loose coupling
to ensure that each layer can be changed at a later date in isolation, without
requiring changes in other layers of the architecture.

Given the above, it's clear that by definition technical architecture design
cannot commence until user requirements have been determined and some analysis
has been carried out (regardless of what some project managers might say). It's
also clear that technical architecture design must be carried out before any
coding takes place.

A useful tip is to have clearly defined performance targets for each of the
user requirements that must be attained by the system, and to test the technical
architecture against those performance requirements very early on in the system
development cycle.