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 5
2. Conceptual architecture
Document 1 derived requirements of the technical IT architecture to support and enable
Emory’s mission, goals, priorities, strategies and strategic information requirements. The next
level of detail, called the Conceptual Architecture, is intended to articulate the important shared
vision and values for the technical architecture process and content. It provides a high-level set
of enterprise-wide principles, strategies, goals, practices, policies, and standards to guide the
design, construction, deployment, and management of enterprise-wide and campus-wide
Information Technology (IT) infrastructure and systems at Emory that support Emory’s technical
architecture requirements. The Conceptual Architecture also identifies categories (called
“architecture domains”) where we need to decide on more specific policies, technologies,
standards, products and configurations.
The goal of the IT architecture is to create an IT environment that can respond to Emory's
needs, delivering needed capability in the needed time frame. What gets in the way of timely
response?
Example 1.
A university has systems and databases for reserving rooms, assigning classrooms to classes,
maintaining standard room and building names, keeping up with the location of equipment, and storing the office
address of staff. Over the years, as each system was added, a separate, unique interface was created to each of the
other systems’ databases to keep them synchronized, resulting in 4 interfaces per system and 10 different pairs of
interfaces in all. With this arrangement, each system must know which other systems to contact and when. Also,
each system duplicates the processing effort to manage communications and handle errors when a database is not
responding. Changes to a database potentially impact all the systems. The complexity of this arrangement makes
adding another system or making changes difficult.
Existing conditions and methods can impede responsiveness. The independent acquisition of
many applications in the past can produce an environment in which integrating new applications
is so complex as to inhibit responding quickly enough. In addition, applications, servers,
networks, and other IT infrastructure must continually be added, upgraded, or expanded to meet
organizational needs. While general requirements can be anticipated (such as a need for more
disk space), the details (such as how much disk space) may be impossible to predict.
The overall approach to creating responsive information technology is to:
n
Anticipate needs based on organizational goals and environmental forces and trends.
n
Investigate IT solutions to anticipated needs.
n
Use tested and successful principles and practices to create a flexible IT environment
that can be quickly adapted as needs change.
¯
For example, reducing complexity can enable faster response by making it easier to
understand the impact of a change. One way to reduce complexity is through
standardization. Having a standard set of clients can lead to a smaller supported set
to test, making for faster testing of a change to a server. Having a standard interface
for exchange of data between applications makes for faster integration of new
applications.
¯
Providing room to grow and having extra equipment at the ready allows for a quicker
increase in capacity.
¯
Creating reusable components with standard interfaces that can be used as building
blocks for systems reduces the time to create new solutions.
 |
 |
 |