[Project Name]
System Architecture Document
Document Overview
Prepared By:
Prepared For:
Date Created:
Last Updated:
(R)esponsible
(A)uthority
(S)upport:
(C)onsult:
(I)nform:
RASCI Alignment
Technical Lead
Technical Manager
ITPD Team/Data Center
ITPD Management/Data Center,
Vendor, System Owner
Project Manager, System Owner
Revision Log
Revision
Date
1.0
1.1
1.2
10/29/2008
11/16/2009
11/30/2009
Initials
AL
AL
1.3
12/02/2009
AL
1.4
1.5
2/4/2009
2/26/2009
AL
AL
Description of Revision
Initial Draft
Technical team review changes
Technical team review changes after discussion with
Arin
Technical team review changes after discussion with
Dave/Brian
Technical team review
Updated version
File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.5.docx
Last Saved: 4/9/2010
Page 8 of 8
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
File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.5.docx
Last Saved: 4/9/2010
Page 8 of 8
<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.>
File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.5.docx
Last Saved: 4/9/2010
Page 8 of 8
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.
File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.5.docx
Last Saved: 4/9/2010
Page 8 of 8
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
File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.5.docx
Last Saved: 4/9/2010
Page 8 of 8
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.?
File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.5.docx
Last Saved: 4/9/2010
Page 8 of 8
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.
File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.3.docx
Last Saved: 2/26/2010
Page 15 of 15
SYSTEM ARCHITECTURE DOCUMENT
PROJECT NAME
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>
File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.3.docx
Last Saved: 2/26/2010
Page 15 of 15
SYSTEM ARCHITECTURE DOCUMENT
PROJECT NAME
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
757
VLAN 758
10.137.1.0/26
CD
CD
HS20
HS20
128.135.100.0/
26
Eragrants-dr
Erairb-dev
Erairb-dr
CD
HS20
Eragrants-dev
1
9
2
10
3
11
4
12
5
13
6
14
7
15
8
16
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
Eradb-dev
CI
L
1
A
L
2
A
L
3
A
L
4
A
L
5
A
L
6
A
L
7
A
L
8
S C O
A
S
CI
Y S T E M S
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
DS-9020-20K9
SAN Switch
1
A
L
2
A
L
3
A
L
4
A
L
5
A
L
6
A
L
7
A
L
8
S C O
A
S
Y S T E M S
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
SAN
Development
SAN Switch
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)>
File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.3.docx
Last Saved: 2/26/2010
Page 15 of 15
SYSTEM ARCHITECTURE DOCUMENT
PROJECT NAME
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
<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.
File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.3.docx
Last Saved: 2/26/2010
Page 15 of 15
SYSTEM ARCHITECTURE DOCUMENT
PROJECT NAME

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.>
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
<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.>
File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.3.docx
Last Saved: 2/26/2010
Page 15 of 15
SYSTEM ARCHITECTURE DOCUMENT
PROJECT NAME
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.]>
File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.3.docx
Last Saved: 2/26/2010
Page 15 of 15
SYSTEM ARCHITECTURE DOCUMENT
PROJECT NAME
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:
Organization: University of Chicago________________
Contractor________________
Approved by:
Signature: ___________________________________________________________________
Name: ______________________________________________________________________
Title:
Date:
Organization: University of Chicago________________
Contractor________________
Approved by:
Signature: ___________________________________________________________________
Name: ______________________________________________________________________
Title:
Date:
File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.3.docx
Last Saved: 2/26/2010
Page 15 of 15