Example: Architectural Decisions |
This example shows the kind of information that might be included in the Architectural Decisions artifact.
Relationships
Related Elements | Architectural Decisions
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 (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
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.