SCOP008 PROJ System Architecture Document Web viewSCOP008_PROJ System Architecture Document_YYYYMMDD_v1 ...

[Project Name]

System Architecture Document

Document OverviewPrepared 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 LogRevision Date Initials Description of Revision

1.0 10/29/2008 Initial Draft1.1 11/16/2009 AL Technical team review changes1.2 11/30/2009 AL Technical team review changes after discussion with

Arin1.3 12/02/2009 AL Technical team review changes after discussion with

Dave/Brian1.4 2/4/2009 AL Technical team review1.5 2/26/2009 AL Updated version

File Name: SCOP008_PROJ System Architecture Document_YYYYMMDD_v1.0_1.5.docx Page 8 of 8Last Saved: 4/9/2010


TABLE OF CONTENTS

REVISION LOG

1) INTRODUCTION 1.1) BUSINESS DRIVERS 1.2) TECHNOLOGY DRIVERS 1.3) OVERVIEW

2) USE CASE VIEW 2.1) USE CASE 2.2) USE CASE SPECIFICATIONS

3) LOGICAL VIEW 3.1) CLIENT SERVICES 3.2) COMMON SERVICES

3.2.1) Application Security Management Service 3.2.2) Access 3.2.3) Connection Pool Manager

3.3) BUSINESS SERVICES 3.3.1) ABC Service

3.4) INFRASTRUCTURE SERVICES 3.5) BATCH PROCESSES 3.6) APPLICATION SERVER 3.7) PERSISTENCE MECHANISM 3.8) DATABASE PACKAGES 3.9) USER INTERFACES

4) PHYSICAL VIEW 4.1) HARDWARE 4.2) USER INTERFACES

5) DEPLOYMENT VIEW 5.1) PROCESS DEPLOYMENT 5.2) APPLICATION NEEDS

5.2.1) Performance 5.2.2) Availability/Reliability 5.2.3) Physical Location 5.2.4) Capacity 5.2.5) Integrity 5.2.6) Access 5.2.7) Management

5.3) DATA NEEDS 5.3.1) Physical Location 5.3.2) Capacity 5.3.3) Integrity 5.3.4) Access 5.3.5) Management

5.4) THIRD-PARTY PRODUCTS 5.5) SOFTWARE INSTALLATIONS 5.6) MAINTENANCE

6) DOCUMENT SIGN OFF


<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 documentsThis use cases are meant to be technical use cases not covered in functional use cases>

2.1) Use Case

< Use Case Name: Provisioning New UserActor: 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 applicationFlow 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. Nameb. CNet IDc. Chicago IDd. 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 user5. 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)>

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


3.6 Sample Application

Client Services Business Services

Infrastructure Services

Browser

3.8 Database

Common Services

Batch Process

3.9 User Interfaces

3.7Persistance mechanism

3.1

3.43.2

3.3

3.5

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 SecurityMenu Level Security is a client level security providing the users only those menu items that they have access to.

Service Level SecurityWhen 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 AuthenticationEach user is authenticated with the security service before they can invoke any of the service.

Package level securityAll 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>

4.1) Hardware

<Describe the hardware components Database


Eradb-dev

I S C O Y S T E M SC S

DS-9020-20K9

4321L L L LA A A A 7 85 6L L L LA A A A L L L LA A A A L L L LA A A A L L L LA A A A9 10 11 12 13 14 15 16 17 18 19 20

I S C O Y S T E M SC S

DS-9020-20K9

4321L L L LA A A A 7 85 6L L L LA A A A L L L LA A A A L L L LA A A A L L L LA A A A9 10 11 12 13 14 15 16 17 18 19 20

VLAN757

128.135.100.0/26

VLAN 75810.137.1.0/26

FirewallVLAN 897 10.4.249.48/29

SAN Development

Eragrants-dev Erairb-dev

AURA Hardware Architecture for Development, DR Environments

Eragrants-dr Erairb-dr

SAN SwitchSAN Switch

CD

HS20

CD

HS20

CD

HS20

PowerEdge M1000e

9 101 2

11 123 4

13 145 6

15 167 8

0

1

00

1

0 0

1

00

1

0 0

1

00

1

0 0

1

00

1

0

0

1

00

1

0 0

1

00

1

0 0

1

00

1

0 0

1

00

1

0

Internet

UsersF5 IP Redirection F5 IP Redirection

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






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






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 Strutso Struts – Layouto Struts – Menuo Display Tago Anto Commonso JSTLo 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: DesignThe (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:


SCOP008 PROJ System Architecture Document Web viewSCOP008_PROJ System Architecture Document_YYYYMMDD_v1 ...

Documents