Information & Technology Management Standards
Application Architecture Document
The Application
Architecture Document provides an overview of how the required functionality
and responsibilities of the system were partitioned and then assigned
to subsystems or components. Include a brief description of the underlying
framework , assumed tools, high-level component interfaces and their
respective interaction to satisfy the business requirements.
The AA document helps to place into perspective how the application
will work and helps to validate:
- Design strategies
(use of patterns) for functions of the application;
- Component classifications
(by types);
- The mapping of
components to the technical architecture;
- How/if meta-data
is being used;
- How the proposed
solution satisfies high-level business requirements; 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 provide the desired functionality.
Deliverable Reviewers
IMG Reviewers |
Other Typical Reviewers |
 |
Database Administrator |
|
ITMB Business Analyst |
|
Technical Architect |
|
Application Support Analyst |
|
Security Administrator |
|
Client Lead |
Related Deliverables
Releated Standards
The Application Architecture Document should conform to the Ministry template (DOC, 209KB) and must include:
- User interface style, including sample screen mock-ups,
- Design strategy for functions of the application,
- Classification of the components by types,
- A mapping of the components to the technical architecture,
- Use of patterns and use of meta data,
- Design deliverables list,
- Performance issues,
- Configuration Management for meta data and components or packages.
|
Guidelines for the Location of Transient Data. Transient data will be located in its own data area on the middle tier. This data area will not be backed up. For the purpose of this guideline, transient data is defined as follows:
- Transient data can be reproduced from the source data in a reasonable amount of time.
- Transient data is not backed up as the data can be reproduced from others sources if needed.
- Transient data should not have a shelf life greater then one year.
Examples of transient data would include:
- Static reports.
- A phone list that is generated from another source
|
| The Implementation Plan should conform to the Ministry template. |
| Standards and Guidelines for Development/Delivery of J2EE Applications. (Revised standards are in development). |
| Web Applications User Interface Guidelines (PDF, 131KB) |
