Example: Architectural Decisions
This example shows the kind of information that might be included in the Architectural Decisions artifact.
Relationships
Related Elements
Description
Main Description

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 (i.e. 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