Your SlideShare is downloading. ×
TRI-UNIVERSITY




     System Wide
Information Technology
     Architecture




                          AUG 2004
      ...
Table of Contents

     Section 1 . . . . Project Team Members


     Section 2 . . . . Project Overview


     Section 3 ...
Project Team Members
                  Project Executive Team
        (During the drafting of the original document)

    ...
 Middleware Domain
              Coordinator: ASU - John Babb
                  Members NAU - Darrel Huish
              ...
TRI-UNIVERSITY




        System Wide
   Information Technology
        Architecture



                     Overview



...
Tri-University IT Architecture - Overview
I. Introduction

This Tri-University IT Architecture (Tri-University ITA)
docume...
B. Assumptions

Several underlying assumptions are used to aid in this
document’s creation:
•  The scope of the Tri-Univer...
hardship.
  Usability
      Easy to use; applicable to university mission.
  Supportability
      University architectural...
-Accommodating increasing costs such as for Software
        licenses and Network Connectivity

It is obvious Academic dis...
-Data: for data exchanges
      -Challenges and opportunities: SSN identifiers, security
      -Vendors and contracts: Inc...
for delivering service. It also encourages further deployment
of open systems based on targeted network architectures that...
design, development, and purchase of software to automate and
maintain Tri-University business processes, and provides a
f...
TRI-UNIVERSITY



        System Wide
   Information Technology
        Architecture




  Target Data/Information
       ...
Tri-University Data/Information Architecture

TABLE OF CONTENTS

   1. Introduction

   2. Data/Information Architecture V...
Tri-University Data/Information Architecture

1.    Introduction

The Tri-University Information Technology Architecture (...
involves data and information unique to a higher education
environment. All these stakeholders increasingly rely upon
accu...
5.    Recommended Data/Information Architecture Strategies

Data/Information strategies and standards are established to
c...
Recommended Strategy 7
Consider web access as key to egalitarian and universal access
to public data or to data used by di...
Recommended Standard 2

XML: Short for Extensible Markup Language. XML is a pared-down
version of SGML, designed especiall...
data to more scrutiny and use.

The Data/Information Architecture must support the business and
program priorities of all ...
Principle 4
Raw data alone is useless; tools must be provided to allow
standard reports and ad-hoc queries in order to tra...
Recommended Best Practice 6
Document not only the data dictionary but also create a “data
confidence” report. Explain why ...
Appendix A. National Institute of Standards and Technology Data
Management Model




Source: The National Institute for St...
Appendix B. Example of a University Data Warehouse Environment




                 Data Warehousing Environment


  Sourc...
Appendix C. Glossary of Terms

These terms are listed here due to their relevance to this
domain. An extensive glossary of...
TRI-UNIVERSITY


        System Wide
   Information Technology
        Architecture




          Target Middleware
      ...
Tri-University Target Middleware Architecture

TABLE OF CONTENTS

1. Introduction

2.    Middleware Architecture Vision/Pu...
Tri-University Target Middleware Architecture

1.    Introduction

The Tri-University Information Technology Architecture ...
services, like authentication and directories, are in all
categorizations. Others, such as co-scheduling of networked
reso...
   Authorization - Those permissions and workflow engines
         that drive transaction handling, administrative
      ...
This group of leading campus IT architects is the
      overarching management structure for I2-MI. Functioning as
      a...
National Institutes of Health (NIH) and National Library
      of Medicine (NLM) and corporate medical software
      prov...
Appendix A. Glossary of Terms

An extensive glossary of terms for the entire ITA document is
available as the last section...
TRI-UNIVERSITY



        System Wide
   Information Technology
        Architecture




              Target Network
    ...
Tri-University Target Network Architecture

TABLE OF CONTENTS

1. Introduction

2.    Network Architecture Vision

3.    N...
Tri-University Target Network Architecture

1.     Introduction

The Tri-University Information Technology Architecture (I...
efficient and effective manner. Network Architecture provides
the framework and foundation to enable university business
p...
protocols (for network access and communication).

4.     Network Architecture Definition

Network Architecture defines co...
6.     Recommended Network Architecture Standards

Network Architecture Standards are established to coordinate
project an...
 All fiber network cabling shall be open, industry-standard as
  supported by IEEE.

 Installation of fiber network cabl...
The standards for transport and network protocols are TCP/UDP
and IP, respectively.

 TCP/UDP and IP makeup an open proto...
three blocks of IP address space for “private” Internets
     (reference Network Working Group Request for Comment (RFC)
 ...
delivery or the location of the customer,

B. accommodating new and expanding applications including
   different types of...
and protect business-critical applications while still enabling
bandwidth-intensive and delay-sensitive multimedia and voi...
    Using multicast, rather than broadcast transmission, to
     distribute messages to multiple points.

Recommended Bes...
Appendix A. OSI Reference Model

The Open Systems Interconnection (OSI) Reference Model,
developed by the International St...
This source for this graphic is The Abdus Salam International
Centre for Theoretical Physics.

The reference model definit...
Appendix A. Glossary of Terms

An extensive glossary of terms for the entire ITA document is
available as the last section...
TRI-UNIVERSITY



        System Wide
   Information Technology
        Architecture




              Target Platform
   ...
Tri-University Target Platform Architecture

TABLE OF CONTENTS


1. Introduction

2. Platform Architecture Vision/Purpose
...
Tri-University Target Platform Architecture

1.    Introduction

The Tri-University Information Technology Architecture (I...
use of e-solutions and maintaining traditional methods of
service delivery to client users.

The Platform Infrastructure S...
interfaces (controllers) and storage devices that
             attach directly to a server or a client. DAS, in the
      ...
for delivery of applications and services to end-
            users, regardless of location.

4.    Platform Architecture ...
Operating System: The device shall utilize either an open,
     industry-standard, secure operating system or a pervasive,...
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Tri-University
Upcoming SlideShare
Loading in...5
×

Tri-University

1,728

Published on

Published in: Education, News & Politics
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,728
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
14
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Tri-University"

  1. 1. TRI-UNIVERSITY System Wide Information Technology Architecture AUG 2004 Updated APR 2007
  2. 2. Table of Contents Section 1 . . . . Project Team Members Section 2 . . . . Project Overview Section 3 . . . . Target Data/Information Architecture Section 4 . . . . Target Middleware Architecture Section 5 . . . . Target Network Architecture Section 6 . . . . Target Platform Architecture Section 7 . . . . Target Security Architecture Section 8 . . . . Target Software/Application Architecture Section 9 . . . . Glossary of Terms Table of Contents - 1 -
  3. 3. Project Team Members Project Executive Team (During the drafting of the original document)  ASU - William Lewis  NAU - Fred Estrella  UA - Sally Jackson Project Executive Team (During the updating of the document)  ASU - Adrian Sanner  NAU - Fred Estrella  UA - Michele Norin Project Manager  ASU - Darel Eschbach University Team Leaders (During the drafting of the original document  ASU - Darrel Huish  NAU - Matt McGlamery  UA - Michele Norin University Team Leaders (During the updating of the document)  ASU - Bob Miller  NAU - Ricky Roberts  UA - Michael Torregrossa Project Domain Work Teams (During the drafting of the original document)  Data/Information Domain Coordinator: ASU - Darrel Huish Members NAU - John Campbell UA – Rick Hargis Section 1 - Project Team Members 1
  4. 4.  Middleware Domain Coordinator: ASU - John Babb Members NAU - Darrel Huish UA - Mike Torregrossa  Network Domain Coordinator: ASU - Darel Eschbach Members ASU - Joe Askin NAU - Matt McGlamery UA - Michele Norin  Platform Domain Coordinator: UofA - Michele Norin Members ASU - John Babb ASU - Darrel Huish NAU - Ricky Roberts UA - Mike Torregrossa  Security Domain Coordinator: UA - Ted Frohling Members ASU - Joe Askins NAU - Lanita Collette  Software Domain Coordinator: NAU - Max Davis-Johnson Members ASU - Darrel Huish UA – Rick Hargis Section 1 - Project Team Members 2
  5. 5. TRI-UNIVERSITY System Wide Information Technology Architecture Overview AUG 2004 Section 2 – Project Overview 1
  6. 6. Tri-University IT Architecture - Overview I. Introduction This Tri-University IT Architecture (Tri-University ITA) document is intended to provide a framework for information technology (IT) use at Arizona’s three state universities. The Tri-University ITA facilitates the application of IT to university initiatives and projects. Its goal is to aid in the efficient and effective implementation of technology on our campuses by describing a direction for current and future IT activities, supported by underlying principles, standards, and best practices. Lastly, it will further facilitate Tri- University collaboration efforts by establishing a common vision for future of IT on our campuses. The use of technology is a large and growing element of the universities' environment and overall expenditures. Arizona’s universities collectively are interested in increasing service quality and saving money through the best possible use of IT. Where feasible, our universities will seek ways to collaborate our efforts to improve our ability to provide cost-effective and technically sound services to our students, faculty and staff. A. Environmental Impacts Certain environmental factors become important in determining the actual implementation of the Tri-University ITA: • Differing university missions can create differences in an institution’s optimal IT architecture. For example, fostering distance learning will have different technological requirements than increasing research efforts in Genomics. • The historical growth of IT on each campus is a powerful factor in determining the ultimate way each campus can implement any IT initiative. • Academic interests frequently dictate the use of a particular communication protocol, database, operating system or application. • The blending of private funds with public funds to achieve institutional objectives creates additional participants with unique technical requirements. • The ratio of centralized vs. decentralized IT resources and management influences the level at which each campus has widespread acceptance of standards and best practices. • Some IT oriented research requires an unstructured environment to conduct experimental constructs that could become the technology of the future. • The diverse and complex nature of any university campus makes the integration and centralization of IT efforts extremely difficult. Section 2 - Project Overview 2
  7. 7. B. Assumptions Several underlying assumptions are used to aid in this document’s creation: • The scope of the Tri-University ITA will focus on the technologies, methodologies and best practices found in industry and in other universities. • This document will remain highly flexible to accommodate the ever-changing nature of IT. • The standards and best practices listed within are guides to creating a high-level framework for establishing our individual campus IT architectures and for evaluating the current and future direction of IT on our campuses. C. Characteristics In order to achieve the overall Tri-University ITA objectives, the following qualitative characteristics are established: Adaptability Change as national & industry standards evolve, so our universities can enhance and incorporate new ways of doing essentially the same business function without major developmental impact. Manageability Centrally manage or coordinate and monitor, including the orderly planning for capacity changes of various essential services. Reliability Remain in continuous operation even if part of the system suffers failure, needs maintenance or upgrading, or is destroyed or damaged by a disaster. Securability Provide different access to individuals based on the classification of data and the user’s business function. Extensibility Easily add new kinds of functionality to existing processes without major impact. Scalability Increase or decrease size or capability in cost-effective increments without software impact or “spikes” in the unit cost of operations due to step functions in procuring additional resources. Performance Fast response and high throughput. Connectability Communications access to a variety of area, national, and international networks. Consistency Relative stability of the person/machine interface over time. Portability University community members should be able to access and use services wherever they are in the world. Accessibility All services should be sensitive to community members with disabilities and provide them equal access without Section 2 - Project Overview 3
  8. 8. hardship. Usability Easy to use; applicable to university mission. Supportability University architectural standards, policies, and guidelines must be followed to ensure support from central IT. Affordability All IT projects should be negotiated to find a reasonably priced solution to meet the universities desired goals. Openness Open-source standards and products should be seriously considered in all IT projects. D. University IT Similarities/Differences Information Technology resources and services have evolved differently at the three Arizona Universities. Many core IT services are centrally provided and coordinated such as network services, administrative and major business systems, and architecture and system design. Where other key IT services are offered varies depending on the culture of the institution, when it began to integrate technology into its operations, and how funding has been prioritized by administration, colleges, and departments within each university. Universities compete for students and the quality and ease of use of IT services are important factors in this competition. The challenge is how to fit the pieces together in an efficient and effective IT foundation for service at each campus, and how to coordinate services among the three institutions. Finding the right fit is not easy. Hardware and software vendors regularly change technology standards. The need for adequate, reliable service raises issues including: security questions, requirement for ubiquitous 24/7 access, information back-up and disaster recovery. The increasingly distributed technology environment at the Arizona universities makes meeting these challenges increasingly complex. IT activities must be coordinated at the highest levels of the university to function effectively. University administration and the campus IT leadership must establish priorities which balance user needs with budget and resource realities to effectively plan, coordinate, manage and support IT resources and services. The goal is to provide seamless, reliable, secure but accessible IT services to current and prospective students, staff, faculty, and to our communities. Key issues related to planning and maintaining the critical network infrastructure include: -Maintaining Reliable Services to support Instruction, Research, Business Services, and Outreach -Accommodating exponential growth in demand -Balancing access with privacy and security -Planning for convergence of voice, data, and video -Managing distributed services and resources Section 2 - Project Overview 4
  9. 9. -Accommodating increasing costs such as for Software licenses and Network Connectivity It is obvious Academic disciplines differ dramatically in the technologies they need for research and teaching. For this reason, the IT resources that are maintained to support Academic IT services vary considerably and are only standardized at levels of a common architecture for network connectivity and desktop equipment. To a slightly lesser degree the same statement is true of the wide range of Administrative services at the three State Universities. Therefore, Academic and Administrative computing requires reliable communication between university resources and user computers. This includes connectivity among departments, classrooms and labs, to central resources, and to the Internet. Communication support (such e-mail and file transfer technology), tools for interaction management (such as calendar systems and workflow software) and tools for collaboration (such as providing shared workspace and files) are also critically important. Each of the three Arizona universities has central IT organizations (Information Technology at ASU, Information Technology Services at NAU, Center for Computing and Information Technology at UA). These organizations provide support for substantial shared resources including hardware, software, technical support, user support, and the institutional IT infrastructure. Differences among systems developed at each University and even within University departments are influenced by a number of factors, which include changes in: -Technology: File structures, databases, mainframes/dumb terminals, personal computers, telephone, Internet/web interfaces. -Vendors: Buy-outs, mergers, etc.; -Product Offerings: SIS, SIS Plus, Exeter, Peoplesoft systems -Resources available: Skilled personnel with appropriate expertise, consultants, fiscal resources, availability of parallel systems to support evaluation and transitions -Leadership: Administration, IT unit, Operational units -Level of centralization/decentralization of IT -Size and age of systems currently in use -Size of institution and geography location -Opportunities: such as State benefit enrollment, ARU -Emerging differing missions and priorities The three universities work together to plan and implement administrative systems and services and coordinate efforts through sharing: -Software: applications, where applicable, and support software Section 2 - Project Overview 5
  10. 10. -Data: for data exchanges -Challenges and opportunities: SSN identifiers, security -Vendors and contracts: Included options for other schools -Ideas: strategic planning and disaster planning -Resources: disaster recovery II. Architecture Components (Domains) The Tri-University project has identified, in part from a literature (web) search and in part from our own experience. The following architecture components or domains are to be documented. Other components may be added as this document lives and matures. Data/Information The Data/Information Architecture defines common, industry- wide, strategies and practices related to managing data and providing information in a university setting. The architecture must support reliable and ubiquitous data/information sharing within the Universities’ distributed information processing environments. It defines technologies, standards, and methodologies currently used to enable information sharing among its internal users, the board of regents, other universities, the federal government, and the public. Middleware Middleware facilitates interchange of information in a distributed, multi-vendor, and heterogeneous systems environment while providing the same levels of security, reliability, and manageability traditionally associated with a monolithic, mainframe-based architecture where all products are supplied by a single vendor. Middleware encompasses a wide range of capabilities from database access to very sophisticated integration. Middleware is intended to provide the glue to tie disparate applications together. The Middleware Architecture describes in a general fashion concepts and directions to be associated with concepts and products that are evolving in this emerging technology area to provide application-to-application integration, business-to- business integration, and business process management. Network The Network Architecture defines network infrastructures providing reliable and ubiquitous communication for the Tri- University’s distributed information processing environment. It defines various technologies required to enable secure connections among all system users, both human and electronic machines. The policy describes a network infrastructure that can support converged services as well as accommodating traditional data, voice, and video services, providing the framework and foundation to enable the Tri-University’s business processes, new business opportunities, and new methods Section 2 - Project Overview 6
  11. 11. for delivering service. It also encourages further deployment of open systems based on targeted network architectures that use common, proven, pervasive, and industry-wide standards. Platform The client and server platforms, with their associated operating systems, provide the end-user interface to the business application. Clients include the personal computer (PC), thin client, host-controlled devices (terminals, telephones, etc.), voice interface devices, single- and multi- function mobile devices (Pocket PC, PDA, PDA-phone, etc.), telephony devices, smart cards, etc. Personal input devices (tablet, keyboard, probe, etc.) and output devices (monitors, displays, projectors, speakers, printers, etc.) attached to a client device should use standard interfaces and industry de facto standard software drivers. The Platform Architecture provides guidance for the hardware devices to be supported and the preferred software interfaces, WEB, Portal as well as dedicated applications. In addition the standard describes common, industry-wide, open-standards-based, interoperable devices facilitating the reliable and pervasive availability of, access interfaces with, and processing for, the Universities' distributed information processing environment. It defines various technologies required to deliver individual units' to all system users. It allows the Universities and individual departments to deploy and support effective and efficient end-user access interfaces to business application systems, as well as providing the processing capability to execute business application systems, while increasing the use of e-solutions and maintaining traditional methods of service delivery to client users. The Platform Infrastructure Standard is intended to be vendor/manufacturer neutral by design, focusing instead on relative versatility, capability to seamlessly interoperate with other platform devices, operating systems, embedded security, adherence to open or pervasive industry standards, provision for open system standard interfaces, and utilization of open standard drivers. Security The Security Architecture provides guidelines to securely and economically protect transaction of the Universities’ business, delivery of services, and communications among all users of the Tri-University systems. It encourages the units to incorporate technology security improvements for business requirements without compromising the security, integrity, and performance of the enterprise and its information resources. Software The Software Architecture delineates common, industry-wide, open-standards-based, interoperable technologies (methodologies, tools, principles, etc.) facilitating the Section 2 - Project Overview 7
  12. 12. design, development, and purchase of software to automate and maintain Tri-University business processes, and provides a foundation for interoperability, integration, collaboration, and communication. The Applications and Related Software Standard guides implementations of software applications that automate business processes. The standard provides for more effective sharing of resources and information among units as well as improved interoperability. III. Architecture Documentation Each component’s documentation includes, at a minimum, the following sections: • Introduction • Vision/Purpose • Standards • Principals • Target Architecture • Recommended Best Practices • Future Technology Trends In addition to the individual components the ITA documentation is supported by a glossary of terms. Section 2 - Project Overview 8
  13. 13. TRI-UNIVERSITY System Wide Information Technology Architecture Target Data/Information Architecture AUG 2004 Section 3 - Data/Information 1
  14. 14. Tri-University Data/Information Architecture TABLE OF CONTENTS 1. Introduction 2. Data/Information Architecture Vision 3. Data/Information Architecture Definition 4. Target Data/Information Architecture 5. Recommended Data/Information Architecture Strategies 6. Recommended Data/Information Architecture Standards 7. Data/Information Architecture Purpose 8. Data/Information Architecture Principles 9. Data/Information Architecture recommended Best Practices 10.Data/Information Architecture Technology Trends Appendix A. National Institute of Standards and Technology Data Management Model Appendix B. Example of a University Data Warehouse Environment Appendix C. Glossary of terms Section 3 - Data/Information 2
  15. 15. Tri-University Data/Information Architecture 1. Introduction The Tri-University Information Technology Architecture (ITA) describes a framework for information technology that supports the Universities’ strategic plans. ITA facilitates change in an orderly, efficient manner by describing a direction for the future that is supported by underlying principles, standards, and best practices. The implementation of ITA presents opportunities for the Universities to interoperate to deliver a higher level of courteous, efficient, responsive, and cost- effective service to their respective communities of interests. Individually, each University can independently implement ITA components that are interoperable. Economies of scale, consolidation, and cross-university savings may best be realized not just through interoperability, but by working together in partnership and sharing. The Tri-University's Information Technology Conceptual Architecture document explains the overall strategic alignment of the ITA with the Universities’ goals and objectives, the principles behind the architecture, the domains to be addressed, the plans for addressing domains, and the technology trends to be taken into consideration. ITA includes important business, governance, and technical components. The technical components collectively referred to in the ITA provide technical guidance to the Universities. That guidance is supported by principles related to unit business functions, recommended standards, and applicable recommended best practices. Tri-University ITA Domains Data/Information Middleware Network Platform Security Software The Data/Information Architecture is one of the ITA domains being developed by the Tri-University architectural task teams. The complete ITA will be developed in phases and updated periodically. The domain architectures, driven by the business and program priorities of the Universities, are aligned with, and facilitate the strategic goals of the State Universities’ Information Technology (IT) plans. 2. Data/Information Architecture Vision The Tri-Universities’ Data/Information Architecture describes strategies and practices that reflect the growing importance of data and information assets in a modern university environment. The Data/Information Architecture strives to support data-driven decision support systems that securely transform data into timely information that is reliable, relevant, and easily accessed in a university setting. The university setting is filled with a variety of internal and external stakeholders and Section 3 - Data/Information 3
  16. 16. involves data and information unique to a higher education environment. All these stakeholders increasingly rely upon accurate and timely digital information in easily accessible formats to inform decision making in business, instruction, research, and shared governance realms. The information age mandates reliable, scalable, secure access to a growing amount of institutional data. The Data/Information Architecture provides the framework and foundation to enable this access. 3. Data/Information Architecture Definition The Data/Information Architecture defines common, industry-wide, strategies and practices related to managing data and providing information in a university setting. The architecture must support reliable and ubiquitous data/information sharing within the Universities’ distributed information processing environments. It defines technologies, standards, and methodologies currently used to enable information sharing among its internal users, the board of regents, other universities, the federal government, and the public. There are many types of data and information in a university setting including unstructured data in the form of web sites, memos, policy documents, operating manuals, and even research notebooks. This document defines Data/Information Architecture as currently concerned with managing only those digital data sources that are recognized as core institutional assets derived from enterprise information sources. Such data are typically captured from various online transaction systems, have some metadata structures that describe the data, and are used to help inform the university decision-making processes. The Educause Core Data survey lists the following information systems as common across nearly all higher education institutions: Student, Financial, Human Resources. Other information systems, such as library, course management, development, and grants management systems may also benefit from considering the strategies and practices described in this architecture document. 4. Target Data/Information architecture The goal of specifying a target Data/Information architecture is to document those strategies, standards, and practices that allow decision support systems and the various stakeholders’ optimal access to data and information subject to necessary security, legal, and technical constraints. In this domain, the architecture is somewhat fluid. While the overall goal of the ITA is to adopt common, industry-wide, open-standards-based infrastructures, the reality of working with proprietary core information systems coupled with the emerging and rapidly evolving nature of web-based data exchange among communities of interest, requires the architecture to remain at a high level of discussion. Such a discussion can illustrate some best practices and targeted standards, but cannot dictate, at this time, the sole platform or the sole standard that all data warehouses or all decision support systems must adopt. Section 3 - Data/Information 4
  17. 17. 5. Recommended Data/Information Architecture Strategies Data/Information strategies and standards are established to coordinate data exchange and encourage data sharing among stakeholders. The goal is to employ open systems based on common, proven, and pervasive strategies and standards. However, Data/Information standards are still evolving and vendors are only now establishing the data exchange mechanisms required for the type of interoperability and federated access that should be the goal of this architecture. Still, there are a few common strategies and standards that everyone should be adopting whenever possible. Recommended Strategy 1 Develop a central data warehouse with appropriate resources for proper management of valuable university data assets. The data warehouse should provide for high availability, scalability, data recoverability, data integrity, data cleansing, etc. Make a clear distinction between the online transaction system(s) and the data reporting system(s) roles. Recommended Strategy 2 Record and agree on the authoritative source for each data element and the access restrictions needed on the data element. In a complex environment where the enterprise applications are of distinct origin, certain data elements may have identical names but represent different functions. In situations where this is unavoidable, the distinctions among the various uses should be well known and completely documented. Recommended Strategy 3 Develop the smallest set of roles and access controls possible given the legal and policy requirements of the state and institution. Centralize the implementation of authorization access control based on these roles, if possible. Recommended Strategy 4 Pay attention to metadata (information about data which describes its various dimensions and uses within the institution). Search for solutions that allow metadata to be stored and collected as part of the extract and load process. Recommended Strategy 5 Use relational databases in all cases where practical. Exception cases would include highly specialized data stores such as Active Directory or LDAP directory information services. Also, some enterprise application databases are so complex and large that a construct (cube, star schema, pre-designed data model) must exist to render them queryable. Recommended Strategy 6 To the extent possible, encourage data sharing by providing easy to use data reporting tools and by supporting federated database efforts. Section 3 - Data/Information 5
  18. 18. Recommended Strategy 7 Consider web access as key to egalitarian and universal access to public data or to data used by distributed stakeholders. This includes the use of XML for data exchange as well as using generic web browsers for data access. Recommended Strategy 8 Continue scanning the data/information communities for new interoperable standards. Those that come from the W3C are increasingly becoming important (e.g. XML, XSD, SOAP, WSDL, UDDI). 6. Recommended Data/Information Architecture Standards A number of standards exist related to Data/Information architectures. Some, like UML data modeling, are not ubiquitous due to their specialized nature (data modeling). Some standards are externally imposed when doing certain types of transactions. ARS 41-132, for example, describes requirements for electronic signatures that mandate certificates and encryptions based on the PKI and PGP standards. Both of these standards can be costly to widely implement in a University environment; their use at this time is best restricted to situations, like legal electronic signatures, that warrant the expense. Likewise, standards involving interoperability and data exchange are still evolving and will continue to evolve as specialized communities of interest begin to work out their data exchange needs. Experience seems to show that many of these interoperability standards, like IMS, continue not only to evolve and change, but also to have a slow adoption rate in higher education product lines. Other standards, like Standard Query Language (SQL) are widely adopted throughout industry and higher education. Some lower level elements, like XML, and SOAP are becoming ubiquitous, but this does not mean that they solve the problem of sharing metadata between applications. Such agreements are just now being ironed out at the semantic level among various communities of interest. Work to define how to share information between applications and business units is continuing. All standards listed here are intended to interact and support relevant standards proposed in the other ITA domains. The network, security, middleware, and client interface standards should be especially relevant. Recommended Standard 1 ANSI SQL: a standardized query language for requesting information from a database. In 1986, ANSI approved a rudimentary version of SQL as the official standard, but most versions of SQL since then have included many extensions to the ANSI standard. In 1991, ANSI updated the standard. Section 3 - Data/Information 6
  19. 19. Recommended Standard 2 XML: Short for Extensible Markup Language. XML is a pared-down version of SGML, designed especially for WEB documents. It allows designers to create their own customized tags, enabling the definition, transmission, validation, and interpretation of data between applications and between organizations. Recommended Standard 3 ODBC: Short for Open DataBase Connectivity, a standard database access method. The goal of ODBC is to make it possible to access any data from any application, regardless of which database management system (DBMS) is handling the data. ODBC manages this by inserting a middle layer, called a database driver, between an application and the DBMS. The purpose of this layer is to translate the application's data queries into commands that the DBMS understands. For this to work, both the application and the DBMS must be ODBC-compliant -- that is, the application must be capable of issuing ODBC commands and the DBMS must be capable of responding to them. Since version 2.0, the standard supports ANSI SQL. Recommended Standard 4 JDBC: Short for Java Database Connectivity, a JAVA API that enables Java programs to execute SQL statements. This allows Java programs to interact with any SQL-compliant database. Since nearly all relational database management systems (DBMSs) support SQL, and because Java itself runs on most platforms, JDBC makes it possible to write a single database application that can run on different platforms and interact with different DBMSs. JDBC is similar to ODBC, but is designed specifically for Java programs, whereas ODBC is language-independent. 7. Data/Information Architecture Purpose The purpose of the Data/Information architecture is to support and encourage data sharing among inter and intra-university constituents. This is in alignment with the strategic goal of increased use of data for decision making and for meeting increased demands on information in governance and in institutional reviews. Increased access to the data and information covered by this architectural plan directly supports the following university activities: A. University reporting B. University decision making C. Improved efficiencies by building and providing data-driven online services. D. Improved data and information quality through exposing more Section 3 - Data/Information 7
  20. 20. data to more scrutiny and use. The Data/Information Architecture must support the business and program priorities of all three Universities. Technology investments in Data/Information Architecture must provide measurable improvements in operations, support public service and facilitate the ABOR’s goals for the Tri-University. The Data/Information Architecture must enable the development of systems that make university information and programs more accessible to our communities of interest. The Data/Information Architecture must increase access to information and services for all faculty, staff, students as well as the general citizens of Arizona, while protecting privacy and fostering openness. The Data/Information Architecture must enable easier access and more widely available information, while still protecting individual rights of privacy. 8. Data/Information Architecture Principles The Data/Information Architecture specifies how information resources are shared and documents the strategies, standards, and best practices for accomplishing these goals. The Data/Information Architecture principles guide the planning, design, and development of database, data warehouse, data mart, data modeling, data mining, and knowledge discovery initiatives focused on the core institutional data assets. Principle 1 The data warehouse provides the primary central repository to support the university’s reporting and information investigation efforts. The warehouse should be designed to optimize data retrieval and involve sound extract, transform, and load principles. Principle 2 Data must be secure and reliably available. High availability, recoverability, and data integrity must be built into the data base management practices for all stages of the data’s life- cycle (from transaction system to data warehouse). Principle 3 Data and information need to be shared more than in the past. Access to data should be the rule rather than the exception. Restrictions on data access should be subject only to the legal and local policy restrictions in place at the institution. Section 3 - Data/Information 8
  21. 21. Principle 4 Raw data alone is useless; tools must be provided to allow standard reports and ad-hoc queries in order to transform the raw data into useful information. To maximize data access, these tools need to be simple to use and be well supported. The best tools are also powerful and allow end-users to drill down into multi-dimensional data sets and extract data transparently into spreadsheets (or other tools) for further analysis. Principle 5 Broad data sharing suggests federated databases and local data marts may be necessary. Access rules and data definitions need to be respected even in these secondary systems. Where possible the same access controls should be extended to ancillary systems and ancillary systems should not duplicate existing data. 9. Data/Information Architecture recommended Best Practices Best Practices are approaches that have consistently been demonstrated by diverse organizations to achieve similar high- level results, which in the case of architecture, means demonstrating the principles. Recommended Best Practice 1 Assure the data warehouse is administered by professional database administrators. Recommended Best Practice 2 Establish the data warehouse using enterprise level database hardware and relational DBMS software capable of scaling to the size and scope required. Assure that backup procedures and resources protect the data assets stored in the data warehouse. Recommended Best Practice 3 Consider using an “Extract Transform and Load” (ETL) tool to migrate data from the transaction systems to the data warehouse. Recommended Best Practice 4 Make data cleansing everyone’s job, promoting feedback loops that correct the data at the source. Data cleansing products might help, especially as mission critical data-driven systems are implemented. Such systems often suffer if the underlying data is inaccurate. Recommended Best Practice 5 Acquire and support a primary reporting tool that has the power and simplicity needed by the majority of campus analysts. Such a tool should have OLAP traits such as transparent download of data, ability to drill down into the data, and ability to interact with the report by changing report parameters. Section 3 - Data/Information 9
  22. 22. Recommended Best Practice 6 Document not only the data dictionary but also create a “data confidence” report. Explain why the data is to be trusted and how it is transformed, cleaned, and loaded into the data warehouse. Document the questions that the data is designed to answer. Recommended Best Practice 7 Most casual access should be through a web interface and should be dynamically generated, and not just statically captured, reports. The better web interfaces even have drill down and parameterized reporting capabilities. 10. Data/Information Architecture Technology Trends Trends, economic, and technical, that impact and influence ITA are to be annually updated. Areas that will require near-term investigation include: • Knowledge discovery and Data Mining • OLAP • Interoperability standards • XML semantic standards (communities of interest) • Data modeling • Centralized access security • Decision support systems • Dashboard or balanced score card reporting Section 3 - Data/Information 10
  23. 23. Appendix A. National Institute of Standards and Technology Data Management Model Source: The National Institute for Standards and Technology. Information Management Directions: The Integration Challenge, NIST Special Publication 500-167, September 1989. Retrieved April 5, 2004 from http://www.faa.gov/niac/pdf/wn18_fia.pdf Section 3 - Data/Information 11
  24. 24. Appendix B. Example of a University Data Warehouse Environment Data Warehousing Environment Source Acquisition Storage Usage Acquire (Data Data Extract Warehouse Transform Load) Section 3 - Data/Information 12
  25. 25. Appendix C. Glossary of Terms These terms are listed here due to their relevance to this domain. An extensive glossary of terms for the entire ITA document is available as the last section of this document. Ad Hoc Query Any query that cannot be determined prior to the moment the query is issued. An ad hoc query consists of dynamically constructed SQL, which is usually constructed by desktop query tools. Business A term that is becoming popular to describe a broad intelligence category of technologies and software for helping organizations make better business decisions. A Data Mart contains a subset of historical information Data Mart from the Data Warehouse. Data Mart’s are focused on a particular subject area. A method used to define and analyze the data requirements Data modeling needed to support the business functions of an enterprise. Data modeling defines the relationships between data elements and structures. Data The Data Warehouse is a comprehensive and centralized Warehouse database for storing institutional information. Allows the university community to assess past performance, develop better forecasts and support business decisions. ETL Extract, Transform and Load. Tools such as Informatica extract data from operational systems, transform the data according to university business rules and load the data into the Data Warehouse. Metadata Data about data. One example is the definition of a data element. Metadata is to the data warehouse what the card catalog is to the traditional library. It is an information directory, containing the yellow pages, a road map, and a list of places of interest for navigating a data warehouse. Operational The Operational Data Store (ODS) is the component of the Data Store Data Warehouse that provides tactical support for the university community. It captures current operational data on a nightly basis. Legacy system A software system found on the mainframe system that is vital to the institution but hard to cope with. Operational Reports generated from the Operational Data Store (ODS). Reports Providing information from the most recent business day. The ability to scale to support larger or smaller volumes Scalability of data and more or fewer users. The ability to increase or decrease size or capability is cost-effective with minimal impact on the services. System of A source of data for the data warehouse. The system of record record, which may consist of legacy databases, extract files, and so on, is treated as the official record. Strategic Reports generated from the Data Warehouse and Data Marts. Reports Providing historical information for statistical, longitudinal and trend analysis. Transactional Reports generated directly from the transactional systems Reports (e.g. student, human resources, and financial systems). Providing on-line, real-time information. Transactional The operational information system from which the Data System Warehouse extracts data, i.e. the university student, human resources, and financial systems. . Section 3 - Data/Information 13
  26. 26. TRI-UNIVERSITY System Wide Information Technology Architecture Target Middleware Architecture AUG 2004 Section 4 - Middleware 1
  27. 27. Tri-University Target Middleware Architecture TABLE OF CONTENTS 1. Introduction 2. Middleware Architecture Vision/Purpose 3. Middleware Architecture Standards 4. Middleware Architecture Principles 5. Middleware Target Architecture 6. Middleware Architecture recommended Best Practices 7. Middleware Architecture Technology Trends Appendix A. Glossary of terms Section 4 – Middleware 2
  28. 28. Tri-University Target Middleware Architecture 1. Introduction The Tri-University Information Technology Architecture (ITA) describes a framework for information technology that supports the universities’ strategic plans. ITA facilitates change in an orderly, efficient manner by describing a direction for the future that is supported by underlying principles, standards, and best practices. The implementation of ITA presents opportunities for the universities to interoperate to deliver a higher level of courteous, efficient, responsive, and cost- effective service to their respective communities of interests. Individually, each university can independently implement ITA components that are interoperable, however, economies of scale, consolidation, and cross-university savings may best be realized not just through interoperability, but also by working together in partnership and sharing. The Tri-University's Information Technology Conceptual Architecture document explains the overall strategic alignment of the ITA with the universities’ goals and objectives, the principles behind the architecture, the domains to be addressed, the plans for addressing domains, and the technology trends to be taken into consideration. ITA includes important business, governance, and technical components. The technical components collectively referred to in the ITA, provide technical guidance to the Universities. That guidance is supported by principles correlated to unit business functions, recommended standards, and applicable recommended best practices. Tri-University ITA Domains Data/Information Middleware Network Platform Security Software The following proposed Middleware Architecture guidelines provide a means to describe middleware implementation at the three universities. Middleware, or "glue", is a layer of software between the network and the applications. This software provides services such as identification, authentication, authorization, directories, and security. In today's Internet, applications usually have to provide these services themselves, which leads to competing and incompatible standards. By promoting standardization and interoperability, middleware will make advanced network applications much easier to use at the three universities. 2. Middleware Architecture Vision/Purpose The items included under the heading of middleware differ depending on who is making the list. These categorizations are all centered around sets of tools and data that help applications use networked resources and services. Some Section 4 – Middleware 3
  29. 29. services, like authentication and directories, are in all categorizations. Others, such as co-scheduling of networked resources, secure multicast, and object brokering and messaging, are the major middleware interests of particular communities, but attract little interest outside of those particular communities. A popular definition of middleware that reflects this diversity of interests is "the intersection of the stuff that network engineers don't want to do with the stuff that applications’ developers don't want to do." Middleware has emerged as a critical second level of the enterprise IT infrastructure. The need for middleware stems from growth in the number of applications, in the customizations within those applications and in the number of locations in our environments. These and other factors now require that a set of core data and services be moved from their multiple instances into a centralized institutional offering. This central provision of service eases application development, increases robustness, assists data management, and provides overall operating efficiencies. 3. Middleware Architecture Standards Interoperable middleware between organizations is a particular need of higher education. Researchers need to have their local middleware work with national scientific resources such as supercomputing centers, scholarly databases, and federal scientific facilities and labs. Advanced network applications will transform instructional processes, but they will depend on middleware to function. The fact that higher education is fractal in structure will create markets that need interoperable standards and products. 4. Middleware Architecture Principals Core middleware services are those that all other middleware services depend upon. The challenges in providing these services are as much political as they are technical. Many of the hardest issues involve the ownership and management of data in the complex world of higher education. 5. Middleware Target Architecture These five services are central to middleware as a whole.  Identifiers - A set of computer-readable codes that uniquely specifies a subject.  Authentication - The process of a subject electronically establishing that it is, in fact, the subject associated with a particular identity.  Directories - Central repositories that hold information and data associated with identities. These repositories are accessed by people and by applications to, for example, get information, customize generic environments to individual preferences, and route mail and documents. Section 4 – Middleware 4
  30. 30.  Authorization - Those permissions and workflow engines that drive transaction handling, administrative applications and automation of business processes.  Certificates and public-key infrastructures (PKI) - Certificates and PKI are related to the previous four core middleware services in several important ways. 6. Middleware Architecture Recommended Best Practices  The software should be loosely coupled. Given uncertainties such as the volatility of the technologies involved, it is likely that middleware will go through a rapid evolution in the next few years. Universities will want to replace and enhance components without having to redo the entire infrastructure.  Software deployments should demonstrate early wins. Given the political aspects of middleware deployment, it will be very useful to show immediate benefits of early components. This will help motivate the significant institutional investments that will be required. Individual components should have value in themselves as well as in concert.  Make software as economically and technically cheap as possible. IT organizations in higher education have limited resources. Financial stresses and employee retention issues suggest keeping software and expertise costs low.  The software systems should accommodate the distinctive aspects of higher education. The higher education IT environment has a number of special characteristics, such as the migratory workstation habits of students, traditions of academic freedom and privacy, and the legal requirements of public institutions. Middleware solutions must accommodate these characteristics.  The software should be easy to use. End users prefer natural naming and intuitive tools. Users may not be able to handle complexity in management of middleware components or personal data. 7. Middleware Architecture Technology Trends The central goal of the Internet2 Middleware Initiative (I2-MI) is to foster the deployment of a "middle layer" of national network connectivity, one that sits on top of the machine-to- machine connectivity of IP, connecting people and objects to the network. The core elements of this layer are identifiers, authentication, directories, authorization and PKI. I2-MI's task is to build from these components a middleware infrastructure that has a coherent architecture that enables applications and provides data for network operations, that is interoperable within higher education and research, and that sheds light on how to build a middleware fabric for the wider society. The major activities of the initiative include the following.  Middleware Architecture Committee for Education (MACE). Section 4 – Middleware 5
  31. 31. This group of leading campus IT architects is the overarching management structure for I2-MI. Functioning as an informal advisory board for middleware, MACE provides both technical and programmatic direction for the rest of the initiative, and will play a critical role in middleware development within higher education. MACE is establishing working groups in three areas: directories, PKI, and web authentication and authorization.  Early Harvest and Early Adopters. The Early Harvest technical workshop brings together leading campus IT practitioners to establish a set of best practices for identifiers, authentication and directories. Early Adopters, the campus testbed phase of Early Harvest, is pushing forward the deployment of core middleware at currently 11 US campuses. Based on this experience, Early Adopters will develop roadmaps for other campuses to follow in their own deployments. Both Early Harvest and Early Adopters are funded by the National Science Foundation (NSF).  PKI Activities. I2-MI is working with the federal government in PKI developments. I2 is also working with Educause and CNI to establish a coherent vision for a PKI for higher education. In order to catalyze research and establish testbeds for interoperability, I2-MI is also beginning to define higher-education-specific research issues within PKI.  Shibboleth. A shibboleth is a word (or other identifier) by which one group of people (or computers) can recognize another. In the Shibboleth project, I2-MI is working with IBM to define the functional requirements for an inter- institutional resource-sharing infrastructure. If the functional specifications point to a solution, that solution will be implemented, allowing users from one campus to use their local credentials to access restricted resources on the web servers of other, remote campuses. This work is intended to lead to the broad distribution of an Apache server module that will permit resource sharing, requiring only that participating institutions maintain a standard deployment of authentication and directory services.  The Beta Grid. The Beta Grid is an NSF effort that will deploy 20 to 100 advanced computational and storage nodes at a similar number of universities, and that will interconnect these servers into a seamless computing environment. This will enable distributed computations, co-scheduling of network resources, high-volume data flows, and real-time manipulation of data. I2-MI will work to anchor these advanced services in the emerging common campus middleware infrastructure.  Medical middleware. One "vertical" market of particular interest to higher education involves the complex set of issues associated with medical schools. As important parts of both campus and health service environments, medical schools present significant challenges to middleware deployment. Through Early Adopters, among whose eleven campuses are eight with medical schools, and through working with national medical organizations such as Section 4 – Middleware 6
  32. 32. National Institutes of Health (NIH) and National Library of Medicine (NLM) and corporate medical software providers, I2-MI is developing approaches to core middleware services that will meet the demanding requirements of medical schools.  Directories. With the loose management structures of institutions of higher education, their need for inter- institutional interoperability, and complex public regulations, directories within higher education present major design and implementation issues. Efforts are underway to evaluate the need for a common database and directory subschema for educational institutions. Section 4 – Middleware 7
  33. 33. Appendix A. Glossary of Terms An extensive glossary of terms for the entire ITA document is available as the last section of this document. Section 4 – Middleware 8
  34. 34. TRI-UNIVERSITY System Wide Information Technology Architecture Target Network Architecture AUG 2004 Section 5 - Network 1
  35. 35. Tri-University Target Network Architecture TABLE OF CONTENTS 1. Introduction 2. Network Architecture Vision 3. Network Architecture Purpose 4. Network Architecture Definition 5. Target Network Architecture 6. Recommended Network Architecture Standards 7. Network Architecture Principles 8. Network Architecture recommended Best Practices 9. Network Architecture Technology Trends Appendix A. OSI Reference Model Appendix B. Glossary of Terms Section 5 – Network 2
  36. 36. Tri-University Target Network Architecture 1. Introduction The Tri-University Information Technology Architecture (ITA) describes a framework for information technology that supports the Universities’ strategic plans. ITA facilitates change in an orderly, efficient manner by describing a direction for the future that is supported by underlying principles, standards, and best practices. The implementation of ITA presents opportunities for the Universities to interoperate to deliver a higher level of courteous, efficient, responsive, and cost- effective service to their respective communities of interests. Individually, each University can independently implement ITA components that are interoperable. Economies of scale, consolidation, and cross-university savings may best be realized not just through interoperability, but by working together in partnership and sharing. The Tri-University's Information Technology Conceptual Architecture document explains the overall strategic alignment of the ITA with the Universities’ goals and objectives, the principles behind the architecture, the domains to be addressed, the plans for addressing domains, and the technology trends to be taken into consideration. ITA includes important business, governance, and technical components. The technical components, collectively referred to in the ITA provide technical guidance to the Universities. That guidance is supported by principles correlated to unit business functions, recommended standards, and applicable recommended best practices. Tri-University ITA Domains Data/Information Middleware Network Platform Security Software Network Architecture is the first ITA domain being developed by the Tri-University architectural task teams. The ITA will be developed in phases and is updated periodically. The domain architectures are driven by the business and program priorities of the Universities, are aligned with, and facilitate the strategic goals of the State Universities’ Information Technology (IT) plans. The technical components of Network Architecture are presented relative to the Open Systems Interconnection (OSI) Network Reference Model as a single reference view of communication to furnish a common ground for analysis, discussion, and standards development. 2. Network Architecture Vision The Tri-Universities’ Network Architecture delineates a reliable, scalable, resilient set of infrastructures that economically support the Universities’ core missions in an Section 5 – Network 3
  37. 37. efficient and effective manner. Network Architecture provides the framework and foundation to enable university business processes, instruction and research, new business opportunities, and new methods for delivering service. 3. Network Architecture Purpose Network Architecture must align with and facilitate the strategic goals of the Universities’ and project IT plans. The key goals of the Tri-University IT Plan that impact requirements for Network Architecture are: A. Increase the use of e-business solutions. B. Effectively share common IT resources to enable the Universities to better serve the people of Arizona. C. Improve access to broadband infrastructure system wide. D. Improve the quality, efficiency, and usefulness of system wide applications integration and data sharing. E. Improve the capability of IT functions in order to deliver quality products and services. Network Architecture must support the business and program priorities of all three Universities. Technology investments in Network Architecture must provide measurable improvements in operations and support public service and should facilitate the ABOR’s goals for the Tri-University. The Network Architecture must enable the development of systems that make university information and programs more accessible to our community of interest. Network Architecture must enable new applications to be developed more rapidly and modified more easily as business requirements change. New systems must be developed to accommodate rapid rates of change in the business and technical environments. Network Architecture must support the use of information technology to continually improve university efficiency and effectiveness. The Network Architecture must define appropriate technology standards while still enabling old and new systems to work together. Network Architecture must increase access to information and services for all faculty, staff, and students as well as the general citizens of Arizona, while protecting privacy and fostering openness. The Network Architecture must enable easier access and more widely available information, while still protecting individual rights of privacy. Network Architecture specifies how information-processing resources are interconnected and documents the standards for topology (design of how devices are connected together), transport media (physical medium or wireless assignments), and Section 5 – Network 4
  38. 38. protocols (for network access and communication). 4. Network Architecture Definition Network Architecture defines common, industry-wide, open- standards-based, interoperable network infrastructures providing reliable and ubiquitous communication for the Universities’ distributed information processing environments. It defines various technologies required to enable connections among its internal users, other universities, federal government, as well as the private business sector. 5. Target network architecture The development of Target Network Architecture addresses all relevant criteria on a broad scale, rather than as part of the deployment of an individual application. The recommendations and decisions that are made during the development process may limit or eliminate certain options for future network components or services. The development of the Target Network Architecture is a collaborative process to allow all application/system/service developers/implementers to participate so that their current investment in certain products and services can be maximized while also developing a transition plan to allow obsolete or non-conforming elements to be phased out. Maximizing the investment and transitioning these elements should not be seen as mutually exclusive activities, since both are in the best interest of the universities. The development of the Target Network Architecture is a continuous process, which is critically important in an environment where funding to implement may not be immediately available. The ongoing process provides the opportunity to continually refine the Target Network Architecture to keep it aligned with business and educational strategies and requirements, emerging standards, and changing technology. The recommended implementation approach for the Target Network Architecture is as follows: A. Developers/implementers assess their technology position relative to the Target Network Architecture recommendations and develop an implementation plan, including any necessary funding. They incorporate that plan into their project IT Plan. B. Developers/implementers are responsible for the execution of the implementation. C. The universities’ CIOs will ensure that the recommended principles, standards, and best practices are incorporated into all system wide Requests for Proposal that culminate in system wide procurement contracts. It is critical to align the procurement documents and process with the Target Network Architecture to provide projects with a streamlined vehicle to purchase products and services that support the Target Network Architecture. Section 5 – Network 5
  39. 39. 6. Recommended Network Architecture Standards Network Architecture Standards are established to coordinate project and university implementation of network infrastructure. The goal is to employ open systems based on common, proven, and pervasive industry-wide, approved, open standards; however, a full complement of open standards does not yet exist for all components of network infrastructure. Therefore, combinations of open standards, de facto industry standards, and mutually agreed upon product standards are currently required to support the Tri-Universities' heterogeneous operating environment. The recommended standards are contained in this document. All standards are periodically reviewed. Recommended Standard 1 The standard for copper network cabling is Category 6 Unshielded Twisted Pair (UTP).  Category 6 UTP is certified to carry 100/1000 Mbps of data.  Category 6 UTP supersedes Category 5e UTP for new installations.  Category 6 UTP is an industry-standard structured cabling system and has support of the Institute of Electrical and Electronics Engineers (IEEE).  UTP shall be used unless specific issues exist, such as high Electromagnetic Interference (EMI) or long transport distances.  Wiring, cable, connector, and equipment vendors have standardized on Category 6 UTP.  Installation of copper network cabling shall conform to applicable building codes, IEEE, EIA/TIA, and BICSI. Recommended Standard 2 The standards for fiber network cabling are single-mode and multi-mode, depending on requirements.  Intra-building fiber network cabling may be either multi-mode or single-mode. 62.5/125-micron multi-mode fiber is capable of transmitting Gigabit Ethernet up to a distance of approximately 220 meters. 50/125-micron multi-mode fiber is capable of transmitting Gigabit Ethernet up to a distance of approximately 550 meters. 8/125-micron single-mode fiber is capable of transmitting Gigabit Ethernet up to a distance of approximately 5 kilometers.  Inter-building fiber network cabling is both multi-mode and single-mode to allow Gigabit Ethernet and above transmission rates over greater distances as well as maximum flexibility. Section 5 – Network 6
  40. 40.  All fiber network cabling shall be open, industry-standard as supported by IEEE.  Installation of fiber network cabling shall conform to applicable building codes, IEEE, EIA/TIA, and BICSI. Recommended Standard 3 The standards for wireless network connectivity are versions of IEEE 802.11 (LAN) and IEEE 802.16 (MAN) with the relevant security standards, which could be the 802.1x security standard, VPN, LEAP, etc.  Versions of IEEE 802.11 offers relatively high-speed (11Mbps and 54 Mbps) links.  IEEE 802.16 offers Metropolitan Area Networks with up to 66 GHz of performance.  The majority of wireless manufacturers have adopted the IEEE 802.1x security standard in addition to other security standards. Recommended Standard 4 The logical network topology shall be a star. The physical network topology may be a star, ring, or mesh.  Star, ring, and mesh topologies provide the capability to easily add or remove network devices as necessary.  Star, ring, and mesh topologies minimize the effect of connection failures between devices. Recommended Standard 5 The standard for network link layer access protocol is Ethernet, IEEE 802.3 Carrier Sense Multiple Access with Collision Detection (CSMA/CD).  Ethernet is a widely accepted, reliable, stable protocol supported by manufacturers.  Ethernet is scalable; faster versions are emerging to manage the increase of data flow.  100/1000 Ethernet has the bandwidth necessary to support the requirements of converged voice, data, and video applications.  10 GIG Ethernet is the next generation of Ethernet to be deployed. Recommended Standard 6 Section 5 – Network 7
  41. 41. The standards for transport and network protocols are TCP/UDP and IP, respectively.  TCP/UDP and IP makeup an open protocol suite that allows Internet access and the seamless integration of Intranets, Extranets, VPNs, and LANS.  The majority of manufacturers support TCP/IP and TCP/IP enabled products. Recommended Standard 7 Network devices (routers, switches, firewalls, access servers, etc.) shall be manageable with Network Management platforms that use Simple Network Management Protocol (SNMP) and Remote Network Monitoring (RMON).  SNMP is part of the TCP/IP protocol suite.  SNMP and RMON facilitate the exchange of management information between network devices.  SNMP allows for network performance management, isolation and analysis of network problems, and growth planning.  The majority of vendors support SNMP and RMON. Recommended Standard 8 Switching (Layers 2, 3, and 4) technologies are the standard for Local Area Network (LAN) network device connectivity.  Switching at OSI Layers 2, 3, and 4 in a LAN improves network performance by enabling the balancing of network traffic across multiple segments, thus reducing resource contention, providing scalability, and increasing throughput capacity.  Switching at OSI Layers 2, 3, and 4 in a LAN provides enhanced security and network management. Recommended Standard 9 Network Interfaces: Internal networks may use “private” unregistered IP addresses for network workstations and appliances. External network Interfaces shall use “public” registered IP addresses for all external ports on Internetworking devices.  Network Address Translation (NAT) techniques deployed at network boundaries to the Internet enable the widespread reuse of non-unique or unregistered IP Version 4 (IPv4) addresses while still providing the required connectivity to applications and the Internet.  The Internet Assigned Numbers Authority (IANA) has reserved Section 5 – Network 8
  42. 42. three blocks of IP address space for “private” Internets (reference Network Working Group Request for Comment (RFC) 1918). The blocks are 10.0.0.0. – 10.255.255.255, 172.16.0.0 – 172.31.255.255, and 192.168.0.0 – 192.168.255.255. IP addresses outside of these address spaces used as unregistered IP addresses are used without coordination with IANA or an Internet registry.  IP Version 6 (IPv6) will provide for expanded addressing; however, for an indefinite period, both IPv4 and IPv6 will coexist.  “Public” registered IP addresses provide the required uniqueness for Internet and network integrity. All public IP addresses should be traceable to a specific device.  The IANA provides coordination of all “public” IP address space. Recommended Standard 10 Internal workstation network IP addressing may be assigned using Dynamic Host Configuration Protocol (DHCP).  DHCP provides flexibility for growth and migration of networks.  DHCP facilitates and simplifies IP network administration and the addition of workstations and devices to networks.  DHCP address allocation may be (1) an automatic allocation where DHCP assigns a permanent IP address to the workstation; (2) manually allocated and assigned by the DHCP administrator; or (3) dynamically allocated where DHCP assigns an IP address to a workstation for a limited period of time (lease).  Static IP addresses may be used in order to address limited, special security issues. 7. Network Architecture Principles Network Architecture Principles guide the planning, design, and selection of network technology and services. Principle 1 Networks provide the infrastructure to support the universities’ core mission, instruction and research, and administrative processes by: A. enabling access to a wide spectrum of information, applications, and resources, regardless of the method of Section 5 – Network 9
  43. 43. delivery or the location of the customer, B. accommodating new and expanding applications including different types of data (e.g., voice, data, image, and video), and a variety of concurrent users and C. passing data across the network in a timely manner so that business decisions can be based on up-to-date information. Principle 2 Networks must be operational, reliable, and available (24x7) for essential business processes and mission-critical business, instruction and research operations. Reliability, redundancy, and fault tolerance must be built-in, not added on, to ensure that any single point of failure does not have severe adverse effects on business applications or services. Principle 3 Networks must be designed for growth, flexibility, and adaptability. As new processes and systems are developed and new information becomes available, networks must scale to allow for increased demand. Principle 4 Barring special circumstances, networks should use industry- proven, mainstream technologies based on industry-wide, open standards, and open architecture to allow systems to interoperate to reduce communication and integration complexity and provide for the sharing of information across the Tri- University system. Principle 5 Networks must be designed with confidentiality and security of data as a high priority and must be implemented with adherence to security, confidentiality, and privacy policies as well as applicable statutes such HIPPA, FERPA and GLBA, to protect information from unauthorized access and use. Principle 6 Network access to University resources should be a function of authentication and authorization, not of network address to provide access to information, applications, and system resources in a timely and efficient manner to appropriate requesters. Authentication and authorization of users must be performed according to the security rules of the unit and the University. Principle 7 Networks must be designed to be “application aware” (at layer 4) to deliver business-critical application systems. To deliver these services, networks must recognize, classify, prioritize, Section 5 – Network 10
  44. 44. and protect business-critical applications while still enabling bandwidth-intensive and delay-sensitive multimedia and voice applications. 8. Network Architecture recommended Best Practices Best Practices are approaches that have consistently been demonstrated by diverse organizations to achieve similar high- level results, which in the case of architecture, means demonstrating the principles. Recommended Best Practice 1 Position networks for future growth in traffic and expansion of services such as voice/video by implementing:  flexible, open network designs and  networks to carry converged voice, video, data, and image traffic. Recommended Best Practice 2 When industry standards do not yet exist or meet application requirement, use interim, common, proven, and pervasive product- based standards for networks. Recommended Best Practice 3 Network planning must be an integral part of application design and development; it must be continually reviewed in production. Recommended Best Practice 4 Design network-neutral applications. Application code should be isolated from the network-specific code so business rules and data access code can be deployed without regard to the type of network (i.e. WAN or LAN) or redeployed on a different platform, as necessary. Network-neutral applications allow networks to remain scalable and portable. Recommended Best Practice 5 Consider the impact of middleware and data movement on network utilization and performance by:  Performing transactions locally between the resource manager and the queue to minimize network traffic,  Using asynchronous, store-and-forward messaging to limit the scope of transactions and network requirements between remote sites,  Using push technology, rather than client polling, to balance server and network link loading and Section 5 – Network 11
  45. 45.  Using multicast, rather than broadcast transmission, to distribute messages to multiple points. Recommended Best Practice 6 Unit business functions drive network design for redundancy, fault tolerance, and disaster recovery. Recommended Best Practice 7 Units should agree on the use of a common set of tools for network design and documentation to ensures documentation and standard practices are followed and promotes opportunities for sharing and consolidation. Recommended Best Practice 8 Establish technical contacts within the recognized units with responsibility for specified blocks of IP addresses. 9. Network Architecture Technology Trends Trends, economic and technical, that impact and influence ITA are to be annually updated. Areas that will require near-term investigation include GIG and Multi-GIG Ethernet, Communication Convergence, IVp6 and growing security requirements. Section 5 – Network 12
  46. 46. Appendix A. OSI Reference Model The Open Systems Interconnection (OSI) Reference Model, developed by the International Standards Organization (ISO), provides a framework for organizing the various data communications functions between disparate devices. This model is a guideline for developing standards that allow the interoperation of equipment produced by various manufacturers. Control is passed from one layer to the next, starting at the application layer in one station, proceeding to the bottom layer, over the channel to the next station and back up the hierarchy. Systems that conform to these standards and have interoperability as their goal are referred to as open systems. The 7 Layers of the OSI Model This layer supports application and end-user processes. Communication partners are identified, quality of service is identified, user authentication and privacy are considered, and Application any constraints on data syntax are identified. Everything at this layer is application-specific. This layer provides application (Layer 7) services for file transfers, e-mail, and other network software services. Telenet and FTP are applications that exist entirely in the application level. Tiered application architectures are part of this layer. This layer provides independence from differences in data representation (e.g., encryption) by translating from application Presentation to network format, and vice versa. The presentation layer works to transform data into the form that the application layer can (Layer 6) accept. This layer formats and encrypts data to be sent across a network, providing freedom from compatibility problems. It is sometimes called the syntax layer. This layer establishes, manages and terminates connections Session between applications. The session layer sets up, coordinates, and terminates conversations, exchanges, and dialogues between the (Layer 5) applications at each end. It deals with session and connection coordination. Transport This layer provides transparent transfer of data between end systems, or hosts, and is responsible for end-to-end error (Layer 4) recovery and flow control. It ensures complete data transfer. This layer provides switching and routing technologies, creating Network logical paths, known as virtual circuits, for transmitting data from node to node. Routing and forwarding are functions of this (Layer 3) layer, as well as addressing, internetworking, error handling, congestion control and packet sequencing. At this layer, data packets are encoded and decoded into bits. It furnishes transmission protocol knowledge and management and handles errors in the physical layer, flow control and frame Data Link synchronization. The data link layer is divided into two sub layers: The Media Access Control (MAC) layer and the Logical Link (Layer 2) Control (LLC) layer. The MAC sub layer controls how a computer on the network gains access to the data and permission to transmit it. The LLC layer controls frame synchronization, flow control and error checking. This layer conveys the bit stream - electrical impulse, light or radio signal -- through the network at the electrical and Physical mechanical level. It provides the hardware means of sending and (Layer 1) receiving data on a carrier, including defining cables, cards and physical aspects. Fast Ethernet, RS232, and ATM are protocols with physical layer components. Section 5 – Network 13
  47. 47. This source for this graphic is The Abdus Salam International Centre for Theoretical Physics. The reference model definition is from the Webopedia.- The Number one online encyclopedia dedicated to computer technology. Section 5 – Network 14
  48. 48. Appendix A. Glossary of Terms An extensive glossary of terms for the entire ITA document is available as the last section of this document. Section 5 – Network 15
  49. 49. TRI-UNIVERSITY System Wide Information Technology Architecture Target Platform Architecture AUG 2004 Section 6 - Platform 1
  50. 50. Tri-University Target Platform Architecture TABLE OF CONTENTS 1. Introduction 2. Platform Architecture Vision/Purpose 3. Platform Architecture 4. Platform Architecture Standards 5. Platform Recommended Best Practices 6. Future Technology Trends Appendix A. Glossary of Terms Section 6 - Platform 2
  51. 51. Tri-University Target Platform Architecture 1. Introduction The Tri-University Information Technology Architecture (ITA) describes a framework for information technology that supports the Universities’ strategic plans. ITA facilitates change in an orderly, efficient manner by describing a direction for the future that is supported by underlying principles, standards, and best practices. The implementation of ITA presents opportunities for the Universities to interoperate to deliver a higher level of courteous, efficient, responsive, and cost- effective service to their respective communities of interests. Individually, each University can independently implement ITA components that are interoperable. Economies of scale, consolidation, and cross-university savings may best be realized not just through interoperability, but by working together in partnership and sharing. The Tri-University's Information Technology Conceptual Architecture document explains the overall strategic alignment of the ITA with the Universities’ goals and objectives, the principles behind the architecture, the domains to be addressed, the plans for addressing domains, and the technology trends to be taken into consideration. ITA includes important governance and technical components. The technical components collectively referred to in the ITA provide technical guidance to the Universities. That guidance is supported by principles related to unit functions, recommended standards, and applicable recommended best practices. Tri-University ITA Domains Data/Information Middleware Network Platform Security Software The Platform Architecture is one of the ITA domains being developed by the Tri-University architectural task teams. The complete ITA will be developed in phases and updated periodically. The domain architectures, driven by the business and program priorities of the Universities, are aligned with, and facilitate the strategic goals of the State Universities’ Information Technology (IT) plans. 2. Platform Architecture Vision/Purpose The Platform Architecture describes common, industry-wide, open- standards-based, interoperable devices facilitating the reliable and pervasive availability of, access interfaces with, and processing for, the Universities' distributed information processing environment. It defines various technologies required to deliver individual units' to all system users. It allows the Universities and individual departments to deploy and support effective and efficient end-user access interfaces to application systems, as well as providing the processing capability to execute application systems, while increasing the Section 6 - Platform 3
  52. 52. use of e-solutions and maintaining traditional methods of service delivery to client users. The Platform Infrastructure Standard is intended to be vendor/manufacturer neutral by design, focusing instead on relative versatility, capability to seamlessly interoperate with other platform devices, operating systems, embedded security, adherence to open or pervasive industry standards, provision for open system standard interfaces, and utilization of open standard drivers. 3. Platform Architecture Platform Architecture addresses platform devices relative to their: versatility, capability to seamlessly interoperate with other platform devices, operating systems, embedded security, adherence to open or pervasive industry standards, provision for open system standard interfaces, and utilization of open standard drivers. This approach focuses on the functionality of platform technologies to support requirements that enhance services and operational capacities, improve productivity, performance, and public services rather than addressing attributes such as specific platform configurations, explicit devices, and operating system revisions that neither provide a direction for current and future activities nor directly relate to unit functions. PLATFORM ARCHITECTURE CATEGORIES Categories of the Platform Architecture range from enterprise-class mainframe-servers to individual workstations and hand-held computing devices along with the operating systems that control these devices. Platform categories, or tiers, complement each other and maximize the operation and usefulness of various specialized platform devices to address unit requirements. Platform Architecture categories include the following: • Server. The server with its associated operating system provides services requested by clients. Types of servers included are: mainframes, midrange, and network servers (application, file, print, database, etc.). Servers should be positioned to embrace a variety of applications so that, over time, as open-standard operating systems and open-standard interfaces are deployed, the traditional boundary lines between voice, data, and video are eliminated. • Storage. Storage is increasingly recognized as a distinct resource, one that is best thought of separately from the devices (servers, clients) that are its consumers and beneficiaries. Such storage is increasingly shared by multiple servers/clients, and acquired and managed independently from them. Storage solutions should address the State’s requirements for short term, long term, and permanent storage of information. Types of storage include: o Direct Attached Storage (DAS) is comprised of Section 6 - Platform 4
  53. 53. interfaces (controllers) and storage devices that attach directly to a server or a client. DAS, in the form of independent storage devices, RAID arrays, or tape libraries, is the most common storage architecture today. o Network Attached Storage (NAS) is an open-industry- standard, file-oriented, storage implementation where storage devices are connected to a network and provide file access services to server and client devices. A NAS storage element consists of an engine, which implements the file services, and one or more devices, on which data is stored. By connecting directly into a network, NAS technologies allow users to access and share data without impacting application servers. o Storage Area Network (SAN) is an open-industry- standard, data-centric, storage implementation that traditionally uses a special-purpose network that incorporates high-performance communication and interface technologies as a means to connect storage devices with servers. • Client. The client, with its associated operating system, provides the end-user interface to applications. Clients include the personal computer (PC), thin client, host-controlled devices (terminals, telephones, etc.), voice interface devices, single- and multi-function mobile devices (Pocket PC, PDA, PDA- phone, etc.), telephony devices, smart cards, etc. PLATFORM ARCHITECTURE GENERAL PRINCIPLES The planning, design, and development of Platform Architecture are guided by the following general principles that support the Universities’ strategic goals and objectives. • Platform Architecture provides the device infrastructure to support education, research, business and administrative processes. • Servers and storage that support essential processes and mission-critical operations shall be operational, reliable, and available 24x7x365. • Platforms shall use industry-proven, mainstream technologies based on pervasive industry-wide, open interfaces, and open architecture. • Platform operating system security should be based on industry-wide, open standards. • Platform configurations and associated operating system versions should be minimized. • Platform infrastructure should employ open, industry-standard components, using an n-tier model. • Platform infrastructure should be designed for growth, flexibility, and adaptability. • Platform infrastructure should maximize the design and availability of the Target Network Architecture Section 6 - Platform 5
  54. 54. for delivery of applications and services to end- users, regardless of location. 4. Platform Architecture Standards Platform Architecture Standards describe client and server devices along with storage platforms, operating systems, and open system interfaces that provide for interoperability and portability of application systems. The term “platform” applies to servers, storage, and client devices with their respective operating systems, interfaces, and drivers that provide a framework for interoperability, scalability, and portability. Open systems architecture for platforms will further promote the appropriate sharing of information/data and other IT resources. Target platform architecture must incorporate a range of requirements since at any point in time, given the dynamic nature of the information technology industry and platform- product life cycles, a particular target platform device may no longer completely comply with all requirements. This approach allows for maximization of current investments in certain devices and services, as well as the development of transition plans to allow obsolete or non-conforming platform elements to be phased out. Versatility: The device shall be flexible, adaptable, and scalable to provide for new and expanding service requirements. • Capability shall exist for achieving applicable architecture targets without requiring major upgrades and additional costs. • Capability shall exist for delivering and/or providing secure (as defined in the related Security Architecture Domain) end-user interface access to a variety of applications without necessitating substantial modifications, regardless of end-user location. ° Applications include, but are not limited to, e-mail, human resources information systems (HRIS), financial management systems (FMS), Internet, office productivity software, telephony, and voice mail. • Capability shall exist for delivering and/or providing end-user interface access to a wide variety of applications using a fully converged network, regardless of end-user location. • Target Network Architecture standards shall be maximized in the connectivity of devices. • The device shall be scalable, without substantial modification, to allow for increased demands for services and new applications. • Widespread choices for off-the-shelf application solutions, without modifications, shall be available for the device. Section 6 - Platform 6
  55. 55. Operating System: The device shall utilize either an open, industry-standard, secure operating system or a pervasive, industry-standard, secure operating system. • The open or industry de-facto standard operating system currently installed shall be available for all similar devices offered by the manufacturer. • The operating system shall provide for updates to be pushed to, or accepted by, all associated devices. Operating System Security: The device shall have an appropriate level of security functionality incorporated as part of the installed operating system. • Operating system security services, including access, authentication, and authorization techniques, shall align with the Security Architecture Domain and should utilize open standards, where possible. • Logging and security controls for applications, platform, and network levels shall be integrated to eliminate, or at least reduce, redundancies. • Support for integrated LDAP-based directory services shall be available. • Security updates from the operating system shall be capable of being pushed to, or accepted by, all associated devices. • Removals of extraneous services, open ports, etc., shall be enabled from default installations of the operating system, and prevented from returning during subsequent upgrades. Interfaces: The device shall be capable of adhering to applicable, open-system-standard, interface specifications. • Open-systems standards for any particular interface shall be available and in use. • Management using standard SNMP-based management tools shall be enabled. • Network communication protocols shall conform to the Network Infrastructure Standards. • Off-the-shelf devices and peripherals conforming to open-systems standards shall be readily obtainable. • “Personal” input devices (tablet, keyboard, probe, etc.) and output devices (monitors, displays, projectors, speakers, printers, etc.) attached to a client device should use IEEE- standard interfaces and industry de facto standard software drivers. Drivers: The device shall be capable of utilizing input/output (I/O) drivers that incorporate IEEE-standard interfacing and industry de-facto standard software drivers. Section 6 - Platform 7

×