|
- Document
1: "Emory
Priorities and Architectural Requirements"
- This document
gives the requirements that the Technical Architecture is to satisfy
in order to support Emory's mission and goals.
It derives the requirements by first considering the types of
information needed. From those information requirements it determines
the requirements for the technical architecture.
Document 1 discusses the derivation and shows the explicit linkage.
The companion Document 1-A shows the derivation.
|
APPROVED
BY CIRT 1999-2000
This document
was also copy-edited and summarized for presentation to Emory's
Board of Trustees.
|
|
- Document
2: "Designing Emory's IT Architecture"
- Document
2 gives principles for designing and implementing enterprise-wide
IT infrastructure at Emory to support the technical architecture
requirements as developed in Document 1 (above).
Document 2 has a list of architecture domains and a set of principles
for developing the domains.
-
|
ADOPTED
BY CIRT
February 20, 2002
|
|
- Security
Domain Architecture
- This
document gives an architecture for Emory's security infrastructure,
which includes the processes, data feeds, and deployed hardware
and software that serve to electronically protect, preserve and
control access to Emory's information technology assets.
-
|
ADOPTED
BY CIRT
February 20, 2002
|
|
- Directory
Service Domain Architecture
- This document
gives an architecture for a service that would provide a means
to look up official information about Emory people, places and
things that are of Emory-wide applicability and that Emory thinks
authorized people or IT systems should be able to obtain at any
time from anywhere on the Emory network or the Internet.
-
|
ADOPTED
BY CIRT
February 20, 2002
|
|
- Resource
Security Classification— Model and Indicators
- This document
proposes a conceptual model for an asset security classification
scheme in accordance with Security
Architecture Principle A-6. Such a scheme is intended to indicate
the level of protection a resource needs in terms that are understandable
to the owner of the resource and that can be linked to specific
safeguards.
|
DRAFT
FOR DISCUSSION
Version 4.5.2
March 2002
|
|
