1. Summary and Status
This section provides a summary of all the decisions made and their status.
ID
|
Decision
|
Status
|
Last Update
|
AD-001
|
Offload Web content and applications to Edge Servers to improve response time and maximize scalability.
|
DM
|
11May07
|
AD-002
|
The LiUS application architecture will be based on the "Enterprise-Out" architectural variation of the
Online Buying Reference Architecture.
|
DM
|
17May07
|
The following codes indicate the status of decisions:
-
DM – decision made. The decision or recommendation has been made having weighed up the alternatives and stated the
justification.
-
AD – awaiting decision. All information has been gathered to make the decision but no final decision has yet been
made.
-
AI – awaiting information. More information is needed before a decision can be made.
2. Architectural Decisions
Subject Area
|
Content Management
|
Topic
|
Caching
|
Architectural Decision
|
Offload Web content and applications to Edge Servers to improve response time and maximize scalability.
|
ID
|
AD-001
|
Issue or Problem Statement
|
Both static and dynamic content needs to be delivered to multiple, geographically dispersed locations
without unreasonable delays in users receiving that content. At the same time content must be managed
centrally (or at least in as few different locations as possible).
|
Assumptions
|
• Access is required to both static and dynamic content 24 hours a day, 7 days a week with minimal
disruption caused by any down-time of "legacy" systems.
• Response times need to be reasonable (that is, less than 8 seconds) for all users wherever
they are placed.
• Content to be managed in as few locations as possible.
|
Motivation
|
Delivery of content to end users in as short a time as possible is considered to be key to the success
of the LiUS commerce system.
|
Alternatives
|
• Option 1 - Offload Web content and applications to Edge Servers distributed throughout the
network to help improve response time and maximize scalability, without sacrificing centralized control
and management. Content distribution can make fresh content available at all servers and caches in the
network, and IT staff can pre-position content after publication, or based on anticipated demand.
• Option 2 - Perform caching using the application server only. This would mean using the
application servers own caching mechanism for caching dynamic pages centrally but still delivering them
out through the web servers on request.
|
Decision
|
Use option 1.
|
Justification
|
The only viable option given the highly distributed nature of this site.
|
Implications
|
Requires Edge Server technology to be identified and procured.
|
Derived requirements
|
None
|
Related Decisions
|
None
|
AD-002: "Web-Up" vs. "Enterprise-Out" Application Architecture
Subject Area
|
Application Architecture
|
Topic
|
Patterns
|
Architectural Decision
|
The LiUS application architecture will be based on the "Enterprise-Out" architectural variation of the
Online Buying Reference Architecture.
|
ID
|
AD-002
|
Issue or Problem Statement
|
Fundamentally, there is an option to either use the "Web-up" or "Enterprise-Out" architectural
variation of the Online Buying Reference Architecture. Web-Up, is used to very quickly enable a
Web-based buying site without any close integration with back-end systems. Enterprise-Out, emphasizes
extending an existing order processing system to a new Web-based delivery channel. In this case, there
will be very close integration with, and re-use of, existing back-end systems.
Which of the approaches (Web-up or Enterprise-out) would be best suited to the business needs of the
client?
|
Assumptions
|
• LiUS has existing legacy systems including an existing order processing subsystem, inventory
subsystem and catalogue subsystem that support the online buying business process.
• The user experience requires immediate feedback from back-end system to successfully conduct
online buying.
|
Motivation
|
Fundamental to the architectural approach.
|
Alternatives
|
• Option 1 - "Web-Up" allows for one or more point-to-point connections to back-end heritage
applications or databases so that the e-commerce applications can be integrated with existing back-end
applications (for example, inventory management). This application topology typically involves some
form of deferred interaction with the back-end processing of the orders.
• Option 2 - "Enterprise-Out". This is the target topology for those organizations wanting to use
their existing enterprise systems to allow their customers purchasing through the Web. The shopping
experience is achieved through middle-tier application logic. The topology also addresses maintenance
of data on that tier. The application topology supports access to back-end fulfillment systems that
perform functions such as inventory, order management, pricing, shipping, tax calculation, and credit
processing.
|
Decision
|
Use option 2.
|
Justification
|
This is the preferred User-to-Online Buying runtime topology as it allows for immediate confirmation of
order completion combined with other information such as shipping details and volume discount pricing.
This runtime topology involves either a synchronous or asynchronous connection to the back-end, with
synchronous being the preferred choice. This runtime provides on-line access to the back-end systems
during checkout and order completion. 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. Adopting the "Enterprise-Out" over
the "Web-up" approach provides the client with an excellent foundation to extend upon maximizing re-use
and enabling a 'grow-fast' strategy.
|
Implications
|
Integration to existing back-end systems may required extensions to the clients integration
infrastructure including an upgrade to existing versions of the messaging software.
|
Derived requirements
|
None
|
Related Decisions
|
None
|
|