Application Architecture Document



[pic]

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: [Date]

Creation Date: [Date]

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 7

8. APMS Update 8

Revision Log 9

Appendices 10

Approval 11

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 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.

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.

3 Assumptions

Describe any assumptions made for the application architecture of the given application. Example : Java technologies will be used. A key assumption could be that the proposed architecture will run in Ministry standard infrastructure/technologies and tools.

Insert text here.

4 Risks

Any perceived risks associated with the architecture, potential areas of risk may include:

• Suitability of framework to support business requirements; and

•

Data Architecture

Describe the Data Architecture of the application in these sections.

Refer Data Architecture standards on BPP site. Also refer “Data Architecture” section of “BPP Summary” document on BPP site.

1 Conceptual data model (Relational)

Briefly describe the Conceptual Data model(s) of the application and mention the location of the conceptual data model files. It is also recommended to include an image of the Conceptual Data model in this section.

2 Logical data model (Relational)

Describe the Logical Data model(s) of the application and mention the location of the logical data model files. Include an image of the Logical Data model(s) in this section.

3 Physical data model (Relational)

Describe the Physical Data model(s) of the application and mention the location of the physical data model files. Include an image of the Physical Data model(s) in this section.

Component/Services Layout

The layout represents a specific implementation of the component architecture based on the Ministry supported TA.

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.

1 Structural View – Logical Layer (Semantics)

Classify component types and briefly outline the criteria used for identifying components within their respective logical layer and their physical tier orientation. Supports rule discovery, information alignment and interoperability.

2 Behavioural View – State Transition

Classify business rules and relation to functional perspective.

3 Component and/or Services View – Business Use Cases

Provide business and system functional analysis, identifies business scenarios, and optimizes application architecture.

Represent the binding of the component interface definition (high level requirements) and the actual component implementation. Depict component dependencies. Reference patterns, API’s and supported platforms/environments.

Indicate criteria used to validate support for:

• Definition or Adoption of Reusable Components/Framework API’s;

•

•

Business Services Perspective:

Functions (sequences of functions are managed within processes) providing the “means” to deliver service outputs. Functions represent the “bundling of work” to manage the delivery of a service.

Function models are linked to business and system use cases and indicate activities expected of a whole system, or system component.

Insert text here.

Application Module Design Specification

(Design Deliverable List)

List the design deliverables to be developed through the detail design phase. Define tool dependencies, delivery format and traceability options (manual or automated) to assist with impact analysis and configuration management tasks. Example deliverables could include:

Class Diagrams (include reference to diagram element details, i.e. package links, generalizations, dependencies etc.).

• JAVA application packages;

•

•

•

This section is intended to outline a general strategy for mapping requirements to components by type (e.g. what are the basic patterns and naming conventions for the user interface and for data persistence? What are the specific components and mechanisms intended to support generic services such as workflow, reporting, mail out?).

This section should contain a clear outline of what and how the more detailed design is to be delivered and ensure it conforms to the packaging, design delivery and review process standards as outlined by the Ministry Project Delivery Office (PDO) and referenced in the TA.

Insert text here.

User Interface (UI)

Describe the User Interface design information here. Include screen mock up images etc. Reference existing guidelines/standards being followed or identify how proposed solution varies from accepted practice/standard. Business representatives must have been consulted and sign off on the agreed to UI format.

Insert text here.

Special Considerations

Identify and describe impacts on the operational and/or enterprise environment for new software or service requirements introduced to support/implement the application.

Insert text here.

Capacity Plan

This section documents estimates forthe application’s overall disk, processing, memory and networking estimated volumes and the corresponding detailed worksheets that include the details, formulae, and assumptions on which the estimates were based.

Many Ministry operations have extremely high and low usage peaks. This section should describe peak activity periods and locate them within business processing context of the organization.

Use the following criteria to check the quality of this deliverable:

• Do the volumetrics accurately reflect the information from the prerequisites?

• Are the formulas and metrics used to transform the volumetrics into the Capacity Plan based on sound experience or a previous baseline?

• Have all the peripherals required by the system been defined?

• Have all the assumptions been documented in the Sizing Assumptions component?

• Have all additional loads on the system been documented in the Additional Load component?

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.

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 Case |Maximum |Complexity of Use Case |Database Activity |

| | |Response 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. |

|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. |

3 Disk Space Requirement

This table outlines the additional disk space required to support .

|Hardware Component |Additional Disk Space |Annual Growth |Remarks |

| |Required (Mbytes) |(Mbytes) | |

| | | | |

| | | | |

| | | | |

Table: Disk space required to support the .

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.

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.

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.

APMS Update

APMS update required? Yes No

APMS updated/to be updated on (date):

Comments:

Revision Log

Use data format “yyyy-mm-dd”. Versions are numbered. Draft versions begin with the number zero; e.g. the first draft is version 0.1, second draft, 0.2. The first approved draft is 1.0.

|Date |Version |Change Reference |Author |Reviewed by |

|[yyyy-mm-dd] |0.1 | | | |

| | | | | |

| | | | | |

| | | | | |

| | | | | |

| | | | | |

Appendices

Each Appendix must have:

• A separate header, numbered A-Z, with an appropriate descriptive title. Use the Heading TOC Style for each Appendix Header. This style will automatically insert a page break.

•

•

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] | | |

|[Client Approver’s Name] | | |

|[Title] | | |

|[Organization] | | |

|[Project Manager’s Name] | | |

|[Title] | | |

|[Organization] | | |

|[IMG Approver’s Name] | | |

|[Title] | | |

|[Organization] | | |

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download