An IT Architecture for Emory University
Adopted by CIRT
Document 2: Designing Emory’s IT Architecture
February 20, 2002
ITA Version 2.6.1
© 2000 Emory University
Page 10
5. Configuration and implementation principles
The following additional principles follow from the previous principles.
D.
Basic configuration principles
D.1.
When choosing a product to be part of the architecture, avoid the risk of using a
leading-edge product until it is proven in the field. Test leading edge products that
are under consideration to determine how well they work. Thoroughly test products
before putting them into production. Also use prudence related to the size of the risk,
ability to inspect the function of the product and see how well it performs, complexity
of the product, and non-obvious ramifications.
D.2.
Choose systems for the enterprise architecture that support Web-enabled
applications. The goal is to simplify the user environment and increase accessibility
by having a common interface. That is currently a web interface.
D.3.
To the extent possible, choose enterprise systems that support Internet standards,
especially access via TCP/IP. This helps move toward a standard, small set of
protocols.
D.4.
Reduce support costs by reducing the number of supported common software
packages.
D.5.
Consolidate systems management tools to gain better integration and cost control.
D.6.
Reduce support costs by reducing the number of supported vendors.
D.7.
Select configurations that minimize the support labor required.
D.8.
Select cost-effective configurations, but err on the side of over-capacity rather than
over-supporting.
E.
Basic implementation principles
E.1.
Choose a system or product after considerations of university mission and priorities
are determined. Make system decisions after the university makes some basic
determinations about the following items:
E.1.1.
Growth: Must the system accommodate substantial growth parameters,
beyond the current data and transactional volumes?
E.1.2.
Scalability: Must the system, in the light of the suggested growth, be able to
start small and grow continuously in small increments. Alternatively, would
it be acceptable if growth happens in major, discontinuous increments.
E.1.3.
Lock-in: Will it be required to move usage from one system to another?
E.1.4.
Openness: What are the implications to the university if a proprietary
system is used, thus eliminating the option to choose systems components
from many vendors?
E.2.
Consider several criteria when selecting a system or product by including some of
the following: financial viability of the vendor; compatibility with or support by other
products; ability to meet the university requirements; adherence to the predetermined
standards; cost of the supporting infrastructure; availability of skill sets (internal
versus external) to support this system and to use this system; and service terms
and conditions.
E.3.
Before deploying a new technology or product, see if the life of a technology or
product already in use can be extended at a reasonable cost to meet the need.
 |
 |
 |