Technical Architectures for E-Business (Part 1)
- Technical Architectures for E-Business (Part 1)
- Availability
- Performance
- Security
- Transaction Integrity
- Scalability
- Openness/Interoperability
- Conclusion
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
Like this article? We recommend
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.
){kind=link}
){kind=link}
Layered applications architecture.
Technical infrastructure.
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.