SD_002_01

Document Location

File Name Location

ArchitectureDesignTemplate.dotx Process Asset Library

Document Version History

Version Effective Author Details Reviewer Approvers

Date

For previous versions, please refer PIP_Master List.

Confidentiality
This document is distributed on a restricted basis, is commercial in confidence to the recipient,
and may not be used for any purpose other than that associated with a project. The contents of
this document may not be disclosed to any third parties without the expressed advance written
authorisation.

• Introduction
[The introduction of the Architecture Design Document should provide an overview of the entire
Document. It should include the purpose, scope, definitions, acronyms, abbreviations and
references.]

•Purpose
This document provides a comprehensive architectural overview of the system, using a number
of different architectural views to depict different aspects of the system. It is intended to capture
and convey the significant architectural decisions that have been made on the system.

[This section defines the role or purpose of the Software Architecture Document, in the overall
project documentation, and briefly describes the structure of the document. The specific
audiences for the document should be identified, with an indication of how they are expected to
use the document.]

•Scope
[A brief description of what the Software Architecture Document applies to; what is affected or
influenced by this document.

Regarding small projects (defined in Project Management Plan), just need diagram / views and
simple explanation in each section.]

•Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations
required to properly interpret the Software Architecture Document. This information may be
provided by reference to the project Glossary.]

•References
[This subsection should provide a complete list of all documents referenced elsewhere in the
Software Architecture Document. Each document should be identified by title, report number (if
applicable), date, and publishing organisation. Specify the sources from which the references
can be obtained. This information may be provided by reference to an appendix or to another
document.]

•Overview
[This subsection should describe what the following sections of the Software Architecture
Document contain and explain how the Software Architecture Document is organised.]

• Architectural Representation
[This section describes what software architecture is for the current system, and how it is
represented. For Use-Case, Logical, Process, Deployment, and Implementation Views, it should
list the views that are necessary, and for each view, explain what types of model elements it
contains.]

• Architectural Goals and Constraints

[This section describes the software requirements and objectives that have some significant
impact on the architecture, for example, safety, security, privacy, use of an off-the-shelf product,
portability, distribution, and reuse. It also captures the special constraints that may apply: design
and implementation strategy, development tools, team structure, schedule, legacy code, and so
on.]

• Use-Case View
[This section lists use cases or scenarios from the use-case model if they represent some
significant, central functionality of the final system, or if they have a large architectural coverage
- they exercise many architectural elements, or if they stress or illustrate a specific, delicate
point of the architecture.]

• Use-Case Realisations
[This section illustrates how the software actually works by giving a few selected use-case (or
scenario) realisations and explains how the various design model elements contribute to their
functionality.]

• Logical View
[This section describes the architecturally significant parts of the design model, such as its
decomposition into subsystems and packages, and for each significant package, its
decomposition into classes and class utilities. It should show any architecturally significant
classes and describe their responsibilities, as well any key important relationships, operations,
and attributes.]

[The logical view is concerned with the functionality that the system provides to end-users. UML
Diagrams used to represent the logical view include Class diagram, Communication diagram,
and Sequence diagram]

• Overview
[This subsection describes the overall decomposition of the design model in terms of its
package hierarchy and layers.]

• Description
Package Name Description

Package 1

Package 2

…
•Common Sequence Diagram
<Include common sequence diagram of the system>

•Architecturally Significant Design Packages

[For each significant package, include a subsection with its name, its brief description and a
diagram with all significant classes and packages contained within the package.

For each significant class in the package, include its name, brief description, and optionally a
description of some of its major responsibilities, operations and attributes.]

• Development View / Implementation View

[This section describes the overall structure of the implementation model, the decomposition of
the software into layers and subsystems in the implementation model and any architecturally
significant components.]

[The development view illustrates a system from a programmer's perspective and is concerned
with software management. This view is also known as the implementation view. It uses the
UML Component diagram to describe system components. UML Diagrams used to represent
the development view include the Package diagram]

• Process View
[This section describes the system's decomposition into lightweight processes (single threads of
control) and heavyweight processes (groupings of lightweight processes). The section should
be organised by groups of processes that communicate or interact. The main modes of
communication between processes should be described, such as message passing, interrupts,
and rendezvous.]

[The process view deals with the dynamic aspects of the system, explains the system
processes and how they communicate, and focuses on the runtime behaviour of the system.
The process view addresses concurrency, distribution, integrators, performance, and scalability,
etc. UML Diagrams to represent process view include the Activity diagram]

• Physical View / Deployment View

[This section describes one or more physical network (hardware) configurations on which the
software is deployed and run. At a minimum for each configuration it should indicate the
physical nodes (computers, CPUs) that execute the software, and their interconnections (bus,
LAN, point-to-point, and so on.) Also, a mapping of the processes of the Process View onto the
physical nodes should be included.]
[The physical view depicts the system from a system engineer's point-of-view. It is concerned
with the topology of software components on the physical layer, as well as communication
between these components. This view is also known as the deployment view. UML Diagrams
used to represent physical view include the Deployment diagram]

•Overview
[This subsection names and defines the various layers and their contents, the rules that govern
the inclusion to a given layer and also the boundaries between layers. A component diagram
that shows the relations between layers should be included.]

•Layers
[For each layer a subsection with its name should be included, along with an enumeration of the
subsystems located in the layer, and a component diagram.]

• Data View (Optional)

[This is a description of the persistent data storage perspective of the system. This section is
optional if there is little or no persistent data or the translation between the Design Model and
the Data Model is trivial.]

• Size and Performance

[A description of the major dimensioning characteristics of the software that impact the
architecture, as well as the target performance constraints.]

• Quality
[A description of how the software architecture contributes to all capabilities (other than
functionality) of the system: extensibility, reliability, portability, and so on. If these characteristics
have special significance, for example safety, security or privacy implications, they should be
clearly stated.]

• Other Considerations
[This section provides a description of other approach/ solutions that were considered in
selection process for the above architecture, i.e., a brief explanation of advantages and
disadvantages of the selected architecture in comparison with others. It should be a clear
answer to the question why the above architecture is selected for this system, not the others.]
Depends on the nature of the project – TA decides which non-functional requirement is
applicable or not and list all of them here with corresponding solutions.

•Standard Non-Functional Requirement

[Refer to Estimation files/SOW… and List out Non-Function Requirement list here (Standard
NFR List, Web Security NFR List, Mobile Security NFR List…)]

•Scalability
[The web application will support hosting on a load-balanced web server farm.]

•Portability
[The application will be able to be accessed via standard PC/Laptops running the latest MS
Windows operating system.]

•Security
The system shall be designed not to be prone to the OWASP top 10 Web Application Security
and well compliant with data protection rules.

Security Risks:

• A1: Injection

• A2: Cross-Site Scripting (XSS)

• A3: Broken Authentication and Session Management

• A4: Insecure Direct Object References

• A5: Cross-Site Request Forgery (CSRF)

• A6: Security Misconfiguration

• A7: Insecure Cryptographic Storage

• A8: Failure to Restrict URL Access

• A9: Insufficient Transport Layer Protection

• A10: Unvalidated Redirects and Forwards

The detail of items to implement is descripted in the Secure Coding Checklist tab of
CodingReviewChecklist file but it will be tailored before starting the project.
[For data protection, clarify with the client what sensitive data must be secured, how it should be
handled in the system, and provide a solution to protect it.]

•User Interface
[Most effort of development stage including bug fixing is spent on GUI almost. Ex: on iPad
Safari browser, it does not support cancel the action when clicking on the back button, so
implementing the dirty checking for this browser maybe impossible.]

•Usability
[Usability is very important to end-users, so customer will take care much on this. Propose a
solution should count usability will be always good.]

•Performance
[It’s very hard to determine a fixed number such as how many seconds a page will load in an
application until we have an almost completed flow. So, if possible, never commit any fixed
number, instead propose actions for tuning if there is any performance issue occurred.

Solution which is proposed should cover the number of concurrent users which is the main
factor impact quite much on performance.

Many performance issues relate to database design which is not good. Considering tuning
database performance, replication, clustering…

In some case, software solution cannot solve performance issue, considering hardware
configuration includes load balancing (software / hardware) or clustering.]

•Supportability
[Making an application display good on almost browser is always a difficult mission. Considering
limit the browser and its version.

Considering environment on client side and on developer side, if there’re differences may lead
some hard-reproduced issues.]

•Transaction Management
To put corresponding solution

•Exception Handling
To put corresponding solution
 •Logging
To put corresponding solution.

•Software and Licenses {Todo: base on project}

• Client needs to by licenses of the following software:

Windows Server 2012 R2

SQL Server Standard 2012 R2 or above

• Open Source Software

• RabbitMQ

• xUnit, Moq, Specs: For writing the unit and integration testing

• Angular 2

• Automapper

• log4net

• AutoFac

•Deployment model (options)

Scalability is the capability of a system to handle a growing amount of work, or its potential to
be enlarged in order to accommodate that growth. These are some architectural design
suggestions to ensure the Global LTL Online System can be scaled in the future.

• Option 1: high scalability, high availability

The following diagram is based on a proven system architecture which has been running for
over six years with a high volume of traffic, with some added improvements to support fail-over
fully within a data centre.

Figure xxxx. System overview which supports scalability and failover within one data centre.
 No Item Name Description

1 DNS server • Manages DNS records of a domain to map

domain names to IP addresses. Required for
the Web Server.

2 CDN Server • Enable caching static content (JavaScript,

Images and Style Sheet files) via a third-party
component. It enables the browser to load the
cached static content from the nearest CDN
server.

• By enabling CDN support, the end-user can

see the loading of static content in a very
short time.

• Optional

3 Proxy Server (for Load • HTTP load balancer using IIS ARR. We also
Balancing) can apply hybrid solution by using common
open source such as Nginx, HAproxy run on
Linux OS.

4 Web Server • Server that hosts the website with IIS web
server installed. Recommend using IIS 8.x

5 Web farm • A group of web servers that share requests

and workload together.

6 File Server Role • A Windows server that installs the File Server
Role feature which is the built-in to Windows.

• It is recommended to map shared file folders

as Virtual Directories in IIS websites on web
servers.

7 File Sharing Cluster • A group of servers running the File Server

Role feature and configured as a cluster.

• Supports failover

8 Distributed Cache Server / • Redis is an in-memory key-value database,

Redis one of Redis’s features is distributed cache
service.
 • Redis is a No-SQL database that can be used
as a distributed cache service in a load
balanced environment.

• Redis is the most popular distributed cache

component, replacing AppFabric which is not
supported anymore.

• Redis is also used as a backbone for SignalR

which supports notification across servers in
a load balancing environment.

• Recommend using Redis on Linux (CentOS

7)

• Redis also support a stable version for

Windows Server 64 bit.

9 Redis cluster • A group of Redis servers that supports

failover

10 SQL Server mirroring • A feature of SQL Server which supports

failover at the database-level

• Subject to discussion about master database

and application software design.

• Connection String:Data
Source=myServerAddress;Failover
Partner=myMirrorServerAddress; Initial
Catalog=myDataBase;Integrated
Security=True;

11 Principle Database • The primary database in a Mirroring failover

model that the web server will communicate
directly to.

• Principle database will transfer transaction

log to Mirror database regularly.

12 Mirror Database • A standby database that receives transaction

logs from Principle.

• Mirror will become Principle when the current

Principle database is down.
 13 DC / Active Directory • Used for centralizing credentials and
managing resource access permission across
servers.

• File clustering requires enabling Active

Directory for communication among servers

Workflow:

• User requests a page of the domain xyz.com for the first time

• Browser lookups DNS records on the DNS server to identify the ARR cluster’s IP
address

• If CDN is enabled, the browser will download static content from CDN servers, and
dynamic content will be downloaded from the ARR cluster

• Depending on the configuration of ARR, the user’s request will be served by a specified
web server. If sticky session is enabled in ARR, after the second request, all the content
will be served by the web server which has served the first request.

• If a request is made for a media file (thumbnail, video…), content will be served by the
File Sharing cluster.

• If the request relates to the Cache which is implemented in the Application tier, content
will be served by Redis.

As Redis is used as a distributed cache service, all the web servers will return the
identical result if they are given a request for the same cached object.

• Normally, most of requests will relate to the database. With support from Witness,
application software does not need to know whether the principle is down or not. Auto
switching is done in the background without human intervention.

• Option 2: High Scalability, Low Availability

As shown in the above diagram, Option 1 will be costly in terms of buying servers and licenses.
The below diagram describes the system architecture which supports scalability with less
failover capabilities.
Figure xxxx. System overview which supports scalability without failover.

Redis cache server will be merged into the File Server. In this case, Redis will run on Windows
64 bit and is installed as a Windows Service.

•
Project can refer ArchitectureDesign_Example on PAL (Process Asset Library) as an example.

Especially, project applies.NET and uses Common library can use this document and modify it
based on project characteristic. It will save about 70% effort for design document.