Application Architecture Document

Ministry/Agency Name

Complete file/properties to populate fields on this page and in the document headers. To see instructions select Tools/Options Print tab, and make sure that “Hidden Text” is checked. Delete red instructions when filling in the template or select Tools/Options Print tab, and make sure that “Hidden Text” is not checked. Project Name Project #: [###] Application Architecture Document

Prepared by: Author's Name Prepared for: [Company Name] Date Submitted: [Date]

Project Sponsor: Project Sponsor's Name Client Acceptor: [if different than Sponsor] Project Manager: [Project Manager’s Name]

Document Number: 6450-20/[Project Number]/App. Arch. Security Classification: Low Version: 0.1

Last Updated: May 13, 2016 Creation Date: [Date] Application Architecture Document Project Name

Table of Contents

Table of Contents...... 2 1. Introduction...... 3 1.1. Audience...... 3 1.2. Purpose...... 3 1.3. Assumptions...... 3 1.4. Risks...... 3 2. Data Architecture...... 1 2.1. Conceptual data model (Relational)...... 1 2.2. Logical data model (Relational)...... 1 2.3. Physical data model (Relational)...... 1 3. Component/Services Layout...... 2 3.1. Structural View – Logical Layer (Semantics)...... 2 3.2. Behavioural View – State Transition...... 2 3.3. Component and/or Services View – Business Use Cases...... 2 4. Application Module Design Specification (Design Deliverable List)...... 3 5. User Interface (UI)...... 4 6. Special Considerations...... 5 7. Capacity Plan...... 6 7.1. Introduction...... 6 7.2. Sizing Assumptions...... 6 7.3. Disk Space Requirement...... 7 7.4. CPU Requirement...... 7 7.5. Memory Requirements...... 7 7.6. Networking Requirements...... 8 8. APMS Update...... 9 Revision Log...... 10 Appendices...... 11 Approval...... 12

Last revised: 2016-05-13 Page 2 of 15 D:\Docs\2017-12-29\090a58cecbf6d3517eddd63da6083318.doc Security Classification: Low Application Architecture Document Project Name

1. Introduction

This Application Architecture (AA) document provides an overview of how the business needs (functionality and responsibilities) as defined during the business requirements phase are to be implemented. The AA explicitly outlines how the Ministry’s supported technical infrastructure (as defined in the Ministry supplied technical architecture document) will be utilized to support the business initiative. 1.1. Audience The audience for this document includes anyone seeking an understanding for how the applications works to support the business needs within the context of the technological framework supported by the Ministry. 1.2. Purpose The AA document is a perspective on how the application will work and helps to validate:  Design strategies (use of patterns) used in establishing business process/services;  The mapping of components (business services) to the technical architecture;  How/if meta-data is being used;  How the proposed solution satisfies business requirements/needs; and  The application is compatible with the supported operational infrastructure. The purpose of this document is to gain an understanding of how and why the system was decomposed, and how the individual parts work together to fulfill the business needs. 1.3. Assumptions Insert text here. A key assumption is the underlying framework(s) and assumed tools/libraries etc. are 100% compatible with the supported Ministry technical infrastructure as defined in the TA document.

1.4. Risks Insert text here.

Last revised: 2016-05-13 Page 3 of 15 D:\Docs\2017-12-29\090a58cecbf6d3517eddd63da6083318.doc Security Classification: Low 2. Data Architecture

2.1. Conceptual data model (Relational)

2.2. Logical data model (Relational)

2.3. Physical data model (Relational) Application Architecture Document Project Name

3. Component/Services Layout

A process is a sequence of functions (business or application) that accept inputs and has an output which produces the service output.

Insert text here. 3.1. Structural View – Logical Layer (Semantics)

3.2. Behavioural View – State Transition

3.3. Component and/or Services View – Business Use Cases Insert text here.

4. Application Module Design Specification (Design Deliverable List)

Insert text here.

5. User Interface (UI)

Insert text here.

6. Special Considerations

Insert text here.

7. Capacity Plan

7.1. Introduction This section documents the application’s overall disk, processing, memory and networking estimated volumes and costs, and the corresponding detailed worksheets that include the details, formulae, and assumptions on which the estimates were based. Technical team members should review this section and agree it accurately reflects the capacity requirements for the new system.

7.2. Sizing Assumptions The following assumptions have been made that affect the calculation of the capacity requirements: Use Cases The table below lists all of the high frequency and long running use cases in the system.

Use Case Type of Use Maximum Complexity of Use Database Activity Case Response Case Time

Read the table using the following information: Use Case The name or code that identifies the use case. Type of use case Used to group similar use cases. Maximum Response Time The response times required for each use case of the system. The system will be required to meet this target for each use case listed under a simulation of peak load before user acceptance test can begin. Complexity of Use Case A measure of the complexity of the use case. Database Activity The level of database activity performed by the transaction, for example, 4 updates of sales staff details, 10 inserts on the audit table.

Business Cycle - Frequency The table below shows the frequency with which each use case on the system is performed.

Use Case Start of Window End Of Window Transactions/Hour

Read the table using the following information: Use Case The name or code that identifies the user case. Last revised: 2016-05-13 Page 6 of 15 D:\Docs\2017-12-29\090a58cecbf6d3517eddd63da6083318.doc Security Classification: Low Application Architecture Document Project Name

Start of Window The start of the time window for which there is a steady transactions/hour rate. End of Window The end of the time window for which there is a steady transactions/hour rate. Transactions/Hour The number of times the use case is executed during the time window each day.

7.3. Disk Space Requirement This table outlines the additional disk space required to support .

Hardware Additional Disk Annual Remarks Component Space Required Growth (Mbytes) (Mbytes)

Table: Disk space required to support the . 7.4. CPU Requirement calculates its peak use case frequency X times the maximum response time Y as Z (less than 10%). Therefore the application will not require even a single CPU from the Ministry servers even at times of peak load. 7.5. Memory Requirements anticipates having less than 10 concurrent users and will need less than 10M of memory per concurrent customer. This will have no significant impact on the Ministry application servers. 7.6. Networking Requirements expects fewer than X pages to be served per day. Each page will have a total size less than Y K. Therefore no significant load on the Ministry’s Gigabit network is anticipated.

8. APMS Update

APMS update required? Yes No APMS updated/to be updated on (date):

Comments:

Revision Log

Date Version Change Reference Author Reviewed by [yyyy-mm-dd] 0.1

Appendices

Enter content here.

Approval

This document has been approved as the official Application Architecture Document for the Project Name project. Following approval of this document, changes will be governed by the project’s change management process, including impact analysis, appropriate reviews and approvals, under the general control of the Master Project Plan and according to Project Support Office policy.

Prepared by Signature Date

Author's Name [Title] [Organization]

Accepted by Signature Date

[Client Acceptor’s Name] [Title] [Organization]

Approved by Signature Date

[Client Approver’s Name] [Title] [Organization]

[Project Manager’s Name] [Title] [Organization]

[IMG Approver’s Name] [Title] [Organization]

Last revised: 2016-05-13 Page 11 of 15 D:\Docs\2017-12-29\090a58cecbf6d3517eddd63da6083318.doc Security Classification: Low