PLA-System Architecture Document

[Project Name]
System Architecture Document
Document Overview
Prepared By:
Prepared For:
Date Created:
Last Updated:
RASCI Alignment
(R)esponsible Technical Lead
(A)uthority Technical Manager
(S)upport: ITPD Team/Data Center
(C)onsult: ITPD Management/Data Center,
Vendor, System Owner
(I)nform: Project Manager, System Owner
Revision Log
Revision Date Initials Description of Revision

1.0 10/29/2008 Initial Draft
1.1 11/16/2009 AL Technical team review changes
1.2 11/30/2009 AL Technical team review changes after discussion with
Arin
1.3 12/02/2009 AL Technical team review changes after discussion with
Dave/Brian
1.4 2/4/2009 AL Technical team review
1.5 2/26/2009 AL Updated version
File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.5.docx Page 8 of 8

Last Saved: 4/9/2010
TABLE OF CONTENTS
REVISION LOG .................................................................................................... 2
1) INTRODUCTION .............................................................................................. 6
1.1) BUSINESS DRIVERS .............................................................................................................................. 6
1.2) TECHNOLOGY DRIVERS ........................................................................................................................ 6
1.3) OVERVIEW ........................................................................................................................................... 6
2) USE CASE VIEW ............................................................................................. 6
2.1) USE CASE ............................................................................................................................................. 6
2.2) USE CASE SPECIFICATIONS ................................................................................................................... 7
3) LOGICAL VIEW ............................................................................................... 8
3.1) CLIENT SERVICES ................................................................................................................................. 9
3.2) COMMON SERVICES ............................................................................................................................. 9
3.2.1) Application Security Management Service ................................................................................... 9
3.2.2) Access ........................................................................................................................................... 9
3.2.3) Connection Pool Manager ........................................................................................................... 9
3.3) BUSINESS SERVICES ............................................................................................................................10
3.3.1) ABC Service ................................................................................................................................10
3.4) INFRASTRUCTURE SERVICES ...............................................................................................................10
3.5) BATCH PROCESSES ..............................................................................................................................10
3.6) APPLICATION SERVER .........................................................................................................................10
3.7) PERSISTENCE MECHANISM ..................................................................................................................10
3.8) DATABASE PACKAGES ........................................................................................................................10
3.9) USER INTERFACES ...............................................................................................................................10
4) PHYSICAL VIEW ........................................................................................... 11
4.1) HARDWARE .........................................................................................................................................11
4.2) USER INTERFACES ...............................................................................................................................11
5) DEPLOYMENT VIEW ..................................................................................... 11
5.1) PROCESS DEPLOYMENT .......................................................................................................................12
5.2) APPLICATION NEEDS ...........................................................................................................................12
5.2.1) Performance ................................................................................................................................12
5.2.2) Availability/Reliability ................................................................................................................12
5.2.3) Physical Location ........................................................................................................................12
5.2.4) Capacity ......................................................................................................................................12
5.2.5) Integrity .......................................................................................................................................12
5.2.6) Access ..........................................................................................................................................12
5.2.7) Management ................................................................................................................................13
5.3) DATA NEEDS .......................................................................................................................................13
5.3.1) Physical Location ........................................................................................................................13
5.3.2) Capacity ......................................................................................................................................13
5.3.3) Integrity .......................................................................................................................................13
5.3.4) Access ..........................................................................................................................................13
5.3.5) Management ................................................................................................................................13
5.4) THIRD-PARTY PRODUCTS....................................................................................................................14
5.5) SOFTWARE INSTALLATIONS ................................................................................................................14
5.6) MAINTENANCE ....................................................................................................................................14
6) DOCUMENT SIGN OFF ................................................................................. 15

<Instructions for areas in question or requiring more details are provided at the beginning of each
section where appropriate and are colored in blue and should be deleted after completing the
document. This includes this particular paragraph. Remember, areas can always be flagged as
N/A, but be prepared to defend that decision.>
FOREWORD
<This is the high level overview of what a system is doing. Like a building blueprint, it
outlines the major features both physical and functional. It details the type of hardware, if
not the specific hardware. It outlines the dimensions of the architecture by specifying the
boundaries. It builds-in any required security, capacity, performance, maintenance, and
operational needs. It specifies all external and user interfaces to the application. The
application architecture is the vision for what the built system should look like. Although
the architecture may change slightly over time, it gives the designers and developers a
view of what the final product should be.>
SCOPE
<The system architecture covers the high level view of the final system. It will provide the
vision for other more detailed documents. It will cover both the logical, physical and
functional aspects of the application. Although the application architecture is not enough
for a developer to begin building the application, it is necessary for providing a common
vision and determining synchronization points for multiple teams.>
AUDIENCE
<The IT SERVICES system owner should read this document to ensure it captures the
owner’s vision for functionality and presentation. A system architect should read this
document to ensure it adheres to the enterprise architectural vision and philosophy. An
information architect should read this document to ensure it properly captures the
business functionality. An infrastructure architect should read the document to ensure
that the application uses the infrastructure items wherever possible. A technology
architect should read this document to ensure the application properly uses the
appropriate technologies. A system engineer should read this document to understand
the vision and constraints placed on the system. The system engineer will reference this
document when building the system requirements and performing system analysis. A
designer should read this document to ensure his design captures the architect’s intent. A
developer should read this document to ensure the implementation realizes the
architect’s vision of the application.>

1) Introduction
<The Introduction section contains background information, the business driver force and
the technical driver force for the system, and an overview of the system context.
This document addresses the application architecture of <Project Name> application
that will be deployed to support and enhance the work of ….>
1.1) Business Drivers
<Please refer to section Business benefits section 3.5 of the business document
<Project Name> application is developed to enhance the process of … in performing …>
1.2) Technology Drivers
<Project Name> application is developed using a vendor package or if it is home grown

please specify the platform and programming language used>
1.3) Overview
<Please provide a brief overview of the project>
2) Use case view
< The only use cases that should be included here are new and not already defined in other
project documents
This use cases are meant to be technical use cases not covered in functional use cases>
2.1) Use Case
< Use Case Name: Provisioning New User

Actor: Application Administrator (AA)
Pre-conditions/Assumptions: The AA has received a request, and suitable
authorization to add a new user to the application.
Post-conditions: The new user is able to access the application
Flow of Events:
1. The AA confirms that the request includes the following information. (If
any information is missing, the request is returned with a request for the
additional information.)
a. Name
b. CNet ID
c. Chicago ID
d. Role(s)
2. The AA confirms that the indicated user is contained in the payroll feed.
3. The AA copies the user information from the payroll feed to the
application.
4. The AA assigns the requested role to the new user
5. The AA contacts the requester to indicate that the new user has been
provisioned.
Alternative paths: Faculty and other academic users are provisioned automatically.
This process is used only for staff users of the application.
Frequency: New user requests will be batched, and provisioned each Friday
morning.

Notes:
Performance Requirements:>
2.2) Use Case specifications
<Create one for each significant use case.
Use Case Name Label to identify the use case
Actor Role responsible for executing the use case
Pre-conditions
/Assumptions
Post conditions Expected results
Flow of Events Steps to be followed to test the use case
Alternative Paths Other ways to test the use case
Frequency
Notes:
Performance
Requirements

3) Logical View
<The Logical View section describes the static and dynamic aspect of the system in terms of
packages, subsystems, components, and their responsibilities. This view primarily supports
the functional requirements.
The Logical view of this system presented at the most abstract level. (Sample application)>
3.6 Sample Application

Batch Process
3.9 User Interfaces

Client Services Business Services 3.5
Browser
3.1 3.3
3.8 Database
Infrastructure Services
Common Services
3.2 3.4 3.7

Persistance
mechanism
<The App Name Application will be comprised of the following five logical packages of
functionality
 Client Services (MVC Struts, Jetty, etc.)
 Common Services (Shared Client Services, e.g. Security Framework)
 Business Services
 Infrastructure Services
 Batch Process (if applicable)>
3.1) Client Services
<The Client Services will be based on the MVC Model containing view, model and controller
components. These allow the interaction of the client interface with the system and vice versa. The
presentation services also contain the Jetty service responsible for receiving http requests and
forwarding it to the MVC classes.?

SYSTEM ARCHITECTURE DOCUMENT PROJECT NAME
The Client Services contains the MVC Struts Classes>
3.2) Common Services
<The common services are services that are used by both the client and the business services. The main
component is the Application Security Management service.>
3.2.1) Application Security Management Service
<Application Security Management Service (ASMS) is responsible for both client and business service
security. >
3.2.2) Access
<Each user of the system is defined a role that they are associated with. The security of the system is
handled in 4 ways.
 Menu Level Security

Menu Level Security is a client level security providing the users only those menu items that
they have access to.
 Service Level Security
When a service is deployed, the rights of each method invocation are assigned to roles in the
security service database. This would enable service level access only to users who have the
appropriate rights.
 User Authentication
Each user is authenticated with the security service before they can invoke any of the service.
 Package level security
All the oracle tables are accessed through stored procedures. No Table rights are provided to
the users. The rights to execute stored procedures are provided to oracle user IDs that are not
known to the users. Only the services that access the stored procedures are aware of the
oracle user ID through connection pools.>
3.2.3) Connection Pool Manager
<The connection Pool Manager will host a pool of connections to databases X, Y, and Z. The
connection pool manager will provide connections to all the services upon request and add it back to
the pool once the connection is utilized.>
3.3) Business Services
<List out all app specific services/components and a brief description of what they can do. Below is an
example.

3.3.1) ABC Service
<The ABC Service is a general common service that will be used to maintain all the ABC’s. App Name
application will use this service to
 A
 B
 C>
3.4) Infrastructure Services
<Infrastructure Services constitutes the various infrastructure services support security, logging and
various other functionality.
The following are the infrastructure services that App Name application will require:
 Security Service
 Logging Service
 Systems Management Service
 Persistence Service
 Jetty Service>
3.5) Batch Processes
<Please refer to the batch process document>
3.6) Application Server
<Describe the application server if applicable.>
3.7) Persistence Mechanism
< Explain the persistence mechanism if it is available at this time.>
3.8) Database Packages
< All access to the database with the exception of updates and transaction management will be done
using oracle packages.>
3.9) User Interfaces
<Identify the various interfaces (web, fat client, other) and the primary audiences for each>

4) Physical View
<This section describes the physical architecture and characteristics of the hardware environment>
AURA Hardware Architecture for Development, DR Environments
Internet
F5 IP Redirection F5 IP Redirection
Users
Firewall
VLAN 897 10.4.249.48/29
VLAN
VLAN 758
757
10.137.1.0/26
128.135.100.0/
26
HS20
HS20
CD
CD
Eragrants-dev Erairb-dev Eragrants-dr Erairb-dr

HS20
CD
1 2 3 4 5 6 7 8
9 10 11 12 13 14 15 16
0 0 0 0 0 0 0 0
Eradb-dev
1 1 1 1 1 1 1 1
CI S C O S Y S T E M S CI S C O S Y S T E M S
L 1 A L 2 A L 3 A L 4 A L 5 A L 6 A L 7 A L 8 A L 9 A L 10 A L 11 A L 12 A L 13 A L 14 A L 15 A L 16 A L 17 A L 18 A L 19 A L 20 A L 1 A L 2 A L 3 A L 4 A L 5 A L 6 A L 7 A L 8 A L 9 A L 10 A L 11 A L 12 A L 13 A L 14 A L 15 A L 16 A L 17 A L 18 A L 19 A L 20 A
DS-9020-20K9 DS-9020-20K9
0 0 0 0 0 0 0 0
SAN Switch SAN SAN Switch

Development
1 1 1 1 1 1 1 1
PowerEdge M1000e
4.1) Hardware
<Describe the hardware components

 Database
 Application
 Other>
4.2) User Interfaces
<Are there any specific hardware interfaces used for the system (e.g. time clocks, card readers, police
call boxes, biometrics)>

5) Deployment View
<If system promotion and client copy procedures are not used please follow the steps below. If they exist
include the link here>
5.1) Process Deployment
<Insert Deployment diagram>
5.2) Application Needs
5.2.1) Performance
<Describe how performance goals will be achieved>
5.2.2) Availability/Reliability
<Describe how availability and reliability will be achieved) >
5.2.3) Physical Location
<The data required for the App Name application will be stored in one database.
 DB name>
5.2.4) Capacity
<There will be new tables created and will have a retention period required by business.>
5.2.5) Integrity
<Backups of the tables used by the system are already taken care of by existent periodic backups of
the oracle server. The integrity requirements of the system are addressed in the E-R diagram.>
5.2.6) Access
handled in 4 ways.

appropriate rights.

5.2.7) Management
<Specify what interface you are using to manage the application database >
5.3) Data Needs
5.3.1) Physical Location
<The data required for the App Name application will be stored in one database.
 DB name>
5.3.2) Capacity
<There will be new tables created and will have a retention period required by business.>
5.3.3) Integrity
<Backups of the tables used by the system are already taken care of by existent periodic backups of
the oracle server. The integrity requirements of the system are addressed in the E-R diagram.>
5.3.4) Access
handled in 4 ways.

appropriate rights.

5.3.5) Management
<Specify what interface you are using to manage the application database >
5.4) Third-Party Products
<This section identifies the third-party products required by App Name application
 Java 1.4 SDK

 Oracle 9i
 Oracle JDBC 8.0406 Thin Driver
 Struts Tag Libraries
o Jakarta Struts
o Struts – Layout
o Struts – Menu
o Display Tag
o Ant
o Commons
o JSTL
o Log4J
 Jetty
 Linux
 Clear case
 Eclipse or some other IDE>
5.5) Software Installations
<[Describe the expected method of deploying the application into the operational environment. Define
the media and format for deploying the system. For example, the application could be a Java JAR on a
server that each client downloads and installs. Describe the state of the system before and after the
software installation. Define any dependencies on hardware, third party software, or other applications.]>
5.6) Maintenance
<[Describe the approach for routine maintenance, such as software patches. Describe emergency
maintenance procedures, such as backing out an installed version of the application to the previous
version, due to some catastrophic errors in the software.]>

6) Document Sign Off
Phase: Design
The (Deliverable Name) document has been reviewed and found to be consistent with the specifications
and/or documented project requirements. The signature below documents acceptance of this document
and/or work product by the signing authority
Organization: University of Chicago________________ Contractor________________
Approved by:
Signature: ___________________________________________________________________
Name: ______________________________________________________________________
Title:
Date:
Approved by:
Signature: ___________________________________________________________________
Name: ______________________________________________________________________
Title:
Date:
Approved by:
Signature: ___________________________________________________________________
Name: ______________________________________________________________________
Title:
Date:


PLA-System Architecture Document

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

PLA-System Architecture Document

Încărcat de

Drepturi de autor:

Formate disponibile

[Project Name]

System Architecture Document

Revision Date Initials Description of Revision

File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.5.docx Page 8 of 8

REVISION LOG .................................................................................................... 2

File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.5.docx Page 8 of 8

File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.5.docx Page 8 of 8

1.1) Business Drivers

1.2) Technology Drivers

<Project Name> application is developed using a vendor package or if it is home grown

<Please provide a brief overview of the project>

2) Use case view

2.1) Use Case

< Use Case Name: Provisioning New User

File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.5.docx Page 8 of 8

2.2) Use Case specifications

<Create one for each significant use case.

Use Case Name Label to identify the use case

Actor Role responsible for executing the use case

Post conditions Expected results

Flow of Events Steps to be followed to test the use case

Alternative Paths Other ways to test the use case

File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.5.docx Page 8 of 8

3.6 Sample Application

3.9 User Interfaces

3.2 3.4 3.7

3.1) Client Services

File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.5.docx Page 8 of 8

The Client Services contains the MVC Struts Classes>

3.2) Common Services

3.2.1) Application Security Management Service

 Menu Level Security

3.2.3) Connection Pool Manager

3.3) Business Services

File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.3.docx Page 15 of 15

3.4) Infrastructure Services

3.5) Batch Processes

<Please refer to the batch process document>

3.6) Application Server

<Describe the application server if applicable.>

3.7) Persistence Mechanism

< Explain the persistence mechanism if it is available at this time.>

3.8) Database Packages

3.9) User Interfaces

File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.3.docx Page 15 of 15

AURA Hardware Architecture for Development, DR Environments

Eragrants-dev Erairb-dev Eragrants-dr Erairb-dr

SAN Switch SAN SAN Switch

<Describe the hardware components

4.2) User Interfaces

File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.3.docx Page 15 of 15

5.1) Process Deployment

<Insert Deployment diagram>

5.2) Application Needs

<Describe how performance goals will be achieved>

<Describe how availability and reliability will be achieved) >

5.2.3) Physical Location

 Menu Level Security

File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.3.docx Page 15 of 15

5.3) Data Needs

5.3.1) Physical Location

 Menu Level Security

File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.3.docx Page 15 of 15

Organization: University of Chicago Contractor

Organization: University of Chicago Contractor

Organization: University of Chicago Contractor