Table of Contents
An architecture is built based upon the intended use of information, the information technology, and the context within which it will exist. Information systems have always stressed the need for exhaustive user requirements as the driving force behind the design of systems. Of course, the evidence shows that this approach has failed for large systems every time.
In this project, the approach taken was to develop patterns of information use so as not to be overwhelmed by the volume of small details necessary to implement a specific task for a specific function for a specific application. This is better done using prototyping at detailed design time, not at the architectural phase of an information system. The project staff therefore developed a set of common information processing tasks based upon an analysis of user requirements plus interviews with people within the University. The architecture is a response to these patterns of information use across all University activities and related processes which are found in every application. The list of these basic information processing tasks and their definitions are found in Volume 2, Chapter IX: Information Processing Tasks.
A series of prototypes were built as part of the project to ensure that the critical technically-based recommendations were valid and feasible. These prototypes were designed to validate that the client/server mode of computing was feasible, that data from a combination of file servers, remote databases and desktop databases could be integrated on a desktop device in a transparent manner to present a unified look to the user. A prototype was also built that demonstrated the ability to put a graphical user interface on the front of a mainframe application as an interim measure to provide enhanced access to legacy systems.
One prototype was also developed that demonstrated the ability to generate applications representing common information processing tasks (finding, browsing and viewing) with a user-defined interface based upon a template. This application generator demonstrates the feasibility of developing tools that end users could utilize to develop their own applications based on guidelines and standards for interface design. Prototypes were also designed to test the feasibility of an on-line data dictionary, on-line name service and business applications using the client/server technology and databases following industry standards.
The prototypes were tested with end users to see if a graphical, mouse-based, point and click interface could be quickly and easily learned by novice users and whether users preferred this interface over a character-based interface available on the mainframe. Not only did the prototypes demonstrate the technical feasibility of providing access to information stored on distributed sources and the preference by users of the graphical interface, but they also provided end users with the capability to integrate data from these sources with personal productivity tools such a spreadsheet for class roster data.
The large scale components of the architecture are shown in the illustration below. These components are discussed in five categories, called architectural views. Each view is summarized in this section and documented in detail in Volume 2: Technical Supplement.
The client/interface view describes what is required at the user's desktop to provide access to the information processing functionality and improve productivity and work life. It presents software components as well as guidelines and standards for implementing a user interface to information and functionality.
The application view shows how common applications with their resultant high level data flows must be integrated to support the core processes in the University. It provides an evaluation of current applications from a process oriented view. It also presents some expected benefits to be derived by acquiring and enhancing common application software. Local, specialized application software was not considered part of this project although a sample list of such applications is included.
The data and document view describes the need for making information widely available and what is required to make this possible. This view outlines a basic architecture for making information accessible for different purposes. It proposes a set of activities and technical components and describes how they can be organized to ensure awareness, identification, accessibility, authentication and authorization of access, and the efficient and effective processing of data and documents by AIS and end-users. It also recommends that a data and document administration function be created and charged with developing an inventory of data and document types and an enterprise-wide data model. A high level data model is provided as a starting point for this activity. The issues of ownership, stewardship and security of data are also covered with a set of guidelines for consideration.
The system management view makes recommendations for how management of a distributed system can be supported via hardware and software products. This includes managing desktop assets, servers, software distribution and installation, software licenses, networks, security, data, and hardware configurations.
The platform view presents recommendations for hardware and system software that adheres to standards and open and distributed system products. It also suggests the use of standard protocols and a standard look and feel as a platform for desktop devices.
The purpose of all components of the University is to support its mission. The mission encompasses education, research and service areas that are influenced by economic, cultural and political factors.
The University attempts to meet its mission at the highest affordable quality. The work of the University is primarily information based and as a result requires the most cost effective information systems that can be implemented. These information systems impact the users who provide services and the customers who receive services. Customers are both internal to the University as well as external to the formal organization. The work performed by the University community and the services provided should all support the mission.
The mission defines the desired outcomes and the level of quality desired for these outcomes. The organization of University resources into processes for producing the desired outcomes is the dynamic that reflects what work we do and how we do it to support the mission.
The Information Architecture and Process Innovation Project identified four core processes (as shown below) and defined the components related to each process. A process is defined by the inter-related outcomes that it produces in terms of services and products and the events that trigger the activities required to support the process. The flow through a process represents the data and documents that enter into and exit from the activities for a process. Each of the core processes have a set of sub-processes which act as threads of inter-related activities.
These core processes represent the workflow of the University and the services provided by administrative systems to support the mission of the University.
The focal point of these processes is the set of customers that the process is intended to support. The data and document processing required to provide service to customers must be supported by the information architecture. The purpose of process reengineering is to make the processes as streamlined as possible and provide a high level of service to customers. Part of the streamlining requires the use of information technology to permit sharing of data, parallel activities, increased responsiveness and improved quality.
Because process reengineering can pose radical changes in the way work is performed, information technology is the only viable mechanism to support the changes. The manner in which application software is structured and the way data and documents are acquired, stored, accessed and processed is based on a process oriented view of the University rather than the traditional function-oriented view. These views are represented by flow diagrams and other models within the relevant sections of the architecture as shown in Volume 2: Technical Supplement.
Users perform a number of information processing tasks in order to fulfill their responsibilities at the University. The term "users" refers to faculty, staff, students, administrators, vendors and other stakeholders in the University enterprise. Information processing tasks refers to such activities as identifying, finding, browsing, selecting, sorting and creating data (see Volume 2, Chapter IX: Information Processing Tasks, for a full list and definitions).
A critical aspect of the interaction between users and information technologies is the interface through which users "see" the information resources and information system functionality available for performing their information-related work. This interface must be intuitive, easy to use, consistent, helpful, and take advantage of natural human capabilities such as visual processing. Interfaces between work tasks, systems, and processes control the flow of data and documents which determine the efficiency and effectiveness of services and products delivered. The architecture indicates that the users will be able to "see", via the interface on their desktop device, all the information resources available within the University and will also be able to select any resource by simply pointing at it using an interaction device which could be a keyboard, mouse, or even a finger.
The architecture also indicates that the user will be able to "see" the functionality available from the desktop device interface. Functionality such as requisitioning items, registering students, authorizing requests, reading and sending mail, creating documents, responding to student inquiries, payroll, scheduling meetings, scheduling classes, ordering books, etc. will be made visible based upon those functions a user has been authorized to utilize.
Desktop Device: The architecture suggests that users should be capable of performing nearly all their information related tasks via an intelligent, programmable desktop device such as a personal computer, workstation, Personal Digital Assistant (PDA), or a laptop computer. In special cases, even a telephone may be used to complete certain types of information processing tasks. A desktop device may be an IBM PC or compatible, a Macintosh, Unix workstation or X-Windows device. These devices are referred to as the desktop hardware platform. Through the interface on the desktop device, users will be able to identify what information resources are available and what functionality exists for performing their information related work.
The architecture suggests that all individuals who must perform information based activities will require the use of a desktop device in order to achieve the benefits of the end-to-end flow of digital data through processes. This implies that all users will have a desktop device.
Every desktop device must have system software. System software refers to the software required to manage the hardware, personal productivity software, common application software, data and communications available on a computer.
Graphical and Iconic Interfaces: The architecture recommends that all desktop devices support a graphical user interface (GUI) and that all software utilize a GUI. A GUI is an interface that provides the ability to display pictures, icons and images on the screen as well as the ability to move the cursor to any addressable location on the display screen. The architecture recommends the use of color display screens so that color can be used as part of the display. A GUI permits the user to perform operations such as cut and paste, drag and drop and point and click using an interaction device such as a mouse. This improves the productivity of the user by eliminating keystrokes and reduces the cognitive load and number of errors that occur when users have to remember commands.
The architecture proposes a set of guidelines and templates for developing user interfaces to applications and information access software. The purpose of such guidelines and templates is to ensure consistency across application software and hardware. This consistency is intended to provide reduced training time, fewer errors, higher levels of productivity and the substitutability of personnel across application areas. Initially, support will be provided for the Microsoft Windows GUI and subsequently expanded to include the Macintosh, OS/2, and X-Windows interfaces.
Personal Productivity Aids: The architecture indicates that users will have access to personal productivity and common application software. Personal productivity software will include such tools as word processing, spreadsheet, graphics, calculator, time management, message handling (e-mail) and local database management software. The ability to send and receive messages (e-mail) in a transparent manner is one of the most important capabilities for the desktop client. Application software has begun to include e-mail interfaces for immediate notification to end users of status, actions and errors related to functions the software is expected to perform. The architecture specifies that data and documents stored in central site and remote databases can be incorporated into personal productivity tools such as a word processor or spreadsheet. It also indicates that personal productivity tools can be used to create data and documents that can be fed to common applications and a document management system. The architecture suggests that the desktop environment should support group work via software such as e-mail, conferencing, group authoring, group calendar management and data sharing.
Common Applications: Users will have access to all authorized common application software from their desktop device. A common application is software that provides the functionality to perform activities such as purchasing, financial management, asset management, human resource management, student registration, student admissions, student advising, student housing, financial aid, etc. These are common to the entire University in that they are required to support services provided by all units within the University and generate data required to manage the University.
Middleware: Desktop devices also need a type of software called middleware. This software provides the capability for the desktop devices to send and receive messages over the network, access data on other computers, share data among applications, and manage the desktop hardware and software itself.
Data Access: Data access software is required to permit users to find and retrieve data for ad hoc queries so that customized displays, reports and files can be generated on an "as needed" basis. The data access software will include the capability to find and retrieve data and documents that are both within the University as well as those that available anywhere in the world. This requires that data, documents and functionality within the University enterprise must be defined, described and stored in database(s) that can be retrieved, displayed and managed for the user by the desktop environment.
Ad Hoc Queries and Reports (End-User Tools): The need to make ad hoc inquiries and produce customized displays, reports and local data files requires functional software that has powerful, flexible capabilities. Software that utilizes data access standards are required for this purpose. All application software will adhere to industry and national data access standards so as to provide consistency across applications and provide access for ad hoc query and reporting.
Electronic Messaging (e-mail): Sending messages that can include any type of media (text, graphics, images) to others within and outside the University is a requisite for the architecture. Message handling systems include e-mail as well as other components which make it possible to send and receive messages. These components should adhere to standards such as X.400 and the Simple Mail Transfer Protocol (SMTP) to ensure interoperability. Since not all existing e-mail currently adhere to these standards, it will be necessary to provide mail gateways to achieve the goal of seamless inter-connectivity for electronic messaging.
Desktop System Management: Desktop devices are assets to the University and as such must be managed appropriately. Software to perform desktop asset management, configuration management, license management, security, backup and recovery, and software installation from a remote site is critical in managing a distributed computing environment. The architecture recommends the acquisition of such software so as to provide secure, reliable and manageable desktop systems. The architecture also recommends that standard configuration and naming conventions be adopted so as to reduce management difficulties.
Desktop Network Connection: The architecture stipulates that all user desktop devices be connected to a Local Area Network (LAN) along with other users in their workgroup. A workgroup is a set of people who perform the same or highly related set of work activities. All the people in a department generally perform highly related work and therefore may be considered a workgroup. An individual can belong to multiple workgroups for providing different services.
All LAN's in the University system should be based on the ethernet technology. Ethernet is a standardized and reliable method of permitting computers to communicate with each other by sending data packets back and forth. This communication between the desktop client and a server must follow a communications protocol to ensure the accurate, reliable and synchronized sending and receiving of messages. Because it is a widely accepted industry standard, the protocol of choice for the University Information System will be TCP/IP (Transmission Control Protocol/Internet Protocol).
Single Signon: It is recommended that the users have a single signon regardless of how many computer systems they may use during a session. A session refers to all the functions performed by the user from the time of logging on the system until logging off. At the time of logon the user will be authenticated by security mechanisms that guarantee a cost effective level of risk against intruders.
A common application is one that is common to the needs of the University as a whole as opposed to a local application which is only needed by a workgroup such as a department, school or business unit. Purchasing and student registration are considered common applications because they are necessary to the basic functioning of the University and affect a large number of people. A specific report generated for recruiting engineering students is considered a local application.
According to the information architecture all applications will operate in a client/server mode as defined above. Every application will be designed with three relatively independent parts, namely, a graphical user interface (GUI) at the front-end, an SQL compliant database at the back-end, and application logic as the middle part.
Application Structure: The architecture recommends structuring applications around processes rather than functions. The work and data should follow the process flow from end-to-end rather than follow a function flow. This means that data, documents and functionality are designed to support processes rather than a particular function. To users, this means that available functionality is broadened and their responsibilities for work become multidimensional rather than a small set of isolated tasks. To aid the user in managing the increased work responsibilities, workflow software is recommended as discussed above.
Application Integration: The architecture suggests that applications be naturally integrated within and across processes such that the need for bridging software to feed one application program or database from another is minimized. Therefore, when a transaction from one application is generated that carries data required for other applications, the updates for the other application's databases is made at the time the transaction is generated rather than writing separate update programs that must be maintained.
Application Acquisition: The question of when to buy and when to build software for applications is not easy to answer. The architecture provides some guidelines that can help make this decision. Making this decision based on cost alone is a sure road to failure. Software development should be undertaken when no satisfactory commercial product is available to meet the needs of the University. This development should follow an accepted methodology and utilize state-of-the-art software development tools as discussed below.
Application Development: Although most of the common applications will be purchased from commercial vendors (with required customization), there will always be a need to develop applications for local system needs (departments, schools, programs, business units) as well as for specialized common needs for which commercial software does not meet the specifications, e.g. Information Resources Directory and Dictionary. Software should be acquired that permits application development in a client/server mode that can be easily learned and rapidly performed. The use of fourth generation languages (4GL) and visual languages are recommended.
In order to provide the information services and functionality required by users, data and documents within the University must be managed as though they are assets. Data and documents originate from within the University as well as outside the University. These data and documents form the backbone for an information system. The architecture specifies the need for an inventory of all classes of data and documents of value within the University as well as a set of related policies and procedures to ensure the continued acquisition, storage and access to all valuable information.
The architecture recommends that a data and document administration function be developed to manage these information resources and make them known and available to the user community in electronic form. The architecture specifies that industry and national standards be adopted for the structure, format, access and processing of data and documents.
Data Ownership: An important aspect of the architecture is the need to clearly define who owns data, who is authorized to have access to data, who has stewardship of data and what the responsibilities of ownership, stewardship and access are. It recommends that policies regarding these issues be reviewed and amended as necessary.
Data Capture: The architecture advocates that all data and documents of value to the University mission be captured one time, at their source, in digital form, and made available to all who are authorized to use it. This will reduce much of the redundancy of recording, storing, and managing the same data by multiple units in the University. It will require the capability to convert paper documents and data to electronic form through the use of scanners. This is especially true for data and documents that originate external to the University. The use of hand-held devices such as personal digital assistants in conjunction with wireless communication technology is seen as necessary for some applications.
Workflow Assistance: Users generally have work routines which they follow in order to accomplish their responsibilities in a timely, effective and efficient manner. But some work tasks occur sporadically and require special knowledge of procedures, forms, policies, codes, destinations, etc., which can cause frustration and errors. The architecture advocates the use of workflow software to help in these situations. The workflow software also monitors all the work in the system and captures statistics which can be analyzed to determine where bottlenecks occur so that the process can be reengineered.
Data Model: The architecture requires that an enterprise data model be developed and maintained as a mechanism for managing the information resources of the University, developing information system applications, and providing access to information.
The data model is stored and maintained in a data directory/dictionary and is used by all data and document related activities. A high level data model and a list of data objects is presented in Volume 2, Chapter VII: Data Model, as a starting point for building the data model.
Information Resources Repository and Dictionaries: The architecture specifies that data describing the information resources of the University (metadata) be managed through the use of an information resources repository which will contain a data directory and dictionary, a services directory and dictionary, a human resources directory and dictionary, a data model, and other descriptive information about the University enterprise.
Database Management System: The architecture specifies that all data will be managed by an automated database management system (DBMS) that adheres to industry standards. The main industry standard that applies in this area is the Standard Query Language (SQL) and that all databases will be SQL compliant. This provides the ability to share data by having a standard access mechanism. The architecture suggests that the database model to be used is the relational model but that experimentation with an object oriented database model should begin immediately.
Document Management System: The architecture specifies that a document management system be acquired or developed in order to ensure the integrity of documents as an asset for the University. Managing documents has some characteristics that require software designed specially for this purpose.
Authorization: The architecture recognizes that the authorization/approval of documents and events is important to the legal, regulatory and financial obligations of the University and its personnel. Therefore, an electronic approval mechanism is part of the architecture. This is implemented in the form of a matrix of electronic documents and personnel who must authorize specific documents.
Data Storage and Retrieval: Data storage and retrieval can be operationally defined as belonging to three categories, namely, current, historical and archival. Current data is that which is both temporally the most recent and is also accessed the most frequently. This data will be stored on high speed, direct access storage devices. Historical data records the temporal aspects of entities and events in the University environment and is typically used for longitudinal studies, verification, decision support and planning. This data is accessed less frequently than current data and can be stored on slower, less expensive direct access storage devices. Archival data is infrequently accessed and is usually retained to meet legal and regulatory requirements but may also be retained as part of the organizational history and culture. This data can be stored on cheap storage devices with slow access time.
Data Backup and Recovery in a Distributed Environment: The central site system (IBM) that currently retains all the data related to common applications has highly reliable capabilities for backup and recovery of essential data. Data and documents that reside on other systems in the University must be assured reliable backup and recovery as well. Since the architecture advocates a distributed processing and data environment, capabilities must be acquired that will permit network backup and recovery of data and documents.
The architecture requires that all components of the University Information System be integrated such that it appears to the user that they are seamlessly interconnected. This means that applications are connected via the data and documents they generate and the messages they send to each other. Users are also connected by the data they have access to and the messages they e-mail and FAX to each other. It means that applications must be integrated and that messaging services must be available for sending, receiving and routing messages as well as translating user names to device addresses.
This means that a data communications network must be available everywhere and that all users are connected to it.
Desktop devices are connected to a local area network (LAN) which is, in turn, connected to the University backbone network, which is further connected to wide area networks. This gives users the ability to connect their desktop device to their local server for local applications and data, to super servers for common applications and data and to the Internet for interacting with data, individuals and organizations external to the University. This must be possible in a transparent manner such that the user can simply indicate what service, data or functionality is desired and be automatically connected to it.
Network Print Services: Network print services provide the ability to print on any network printer from any location on the network. This provides users with the ability to print data and documents on a printer that meets the requirements of the situation. Likewise, as production printing services such as those provided by Central Printing, are placed on the network, users will have the capability to submit Central Printing jobs from their desktop device or local server and receive the same printing services as currently performed in a manual mode.
Network Management: The management of the network requires good software management tools and communication devices that adhere to the Simple Network Management Protocol (SNMP). As the message load on the network increases, newer and faster communications technologies will need to be implemented as the capacity on some segments of the network are reached. These increases will be due to an increased number of users as well as an increased volume of network traffic due to multimedia communications. Following standards in the networking area is critical because it can guarantee connectivity among devices, applications and databases. It is also recommended that newer technologies such as fast ethernet and ATM be investigated.
Network Security: Security at the network level must be such that only users that have been authenticated can access available network services. This requires network authentication services which have the ability to support a single signon for users and customers. A commercial product that provides authentication services should be acquired. It is also recommended that a single ID card for all users become the basis for security.
A platform is a combination of hardware, system software, networking and related services that support applications and user access to information system resources. This view of the information architecture (IA) provides an overall framework for the infrastructure necessary to accomplish the objectives of the other architectural components and provides a basis for determining hardware and system software acquisitions. It is intended to provide desirable platform objectives using standards and industry forces as important factors for achieving an open systems environment.
An open system, client/server architecture is proposed for the IA in order to achieve its goals and objectives. The client/server architecture is a basic framework for designing and acquiring computer system configurations, networks, applications and databases. Servers are computers that provide some type of service to the devices connected to them. These services are many and varied but the most common types of services are application program execution, authentication of users, database management, file storage, messaging (e-mail), FAX, gateways for mail and databases, system and network management.
The architecture suggests that servers can be classified as local servers for local workgroups, super servers for common applications, common data and documents and mega servers for a data warehouse. The data warehouse is an information repository where all versions of all data and documents are stored. It is a log of all transactions at the University and is intended to be used for decision support, planning, and institutional research where historical data is required.
The system software on servers should adhere to industry standards and utilize open systems features, capabilities and products as specified by Open Software Foundation (OSF), X/Open group and Institute of Electrical and Electronic Engineers (IEEE). Server system management software is required to provide security, communications, configuration, license monitoring, user accounting, backup, etc.
Client/Server Mode of Operation: It is also recommended that the desktop devices and the computers that serve them operate in a client/server mode. A client/server mode of operation is one wherein the desktop device and the server divide up a computing task such that each is utilized in an optimal manner rather than one device performing all the computing functions. The client/serve mode permits the flexibility of acquiring inexpensive computers that are sized to fit the needs of the applications for which they will be used. This is in contrast to the traditional mainframe mode where all computing tasks are performed on one very large and expensive computer system.
Peripheral Devices: The architecture recommends specialized devices that provide services for acquiring data and documents, interacting with the desktop device, tracking and monitoring assets, archiving and storing data and documents in all media, and interacting with individuals with handicaps. The importance of acquiring data and documents in electronic form requires the use of scanners that can acquire text as well as graphic and image data. The capability to print digital information using color is recommended where it is appropriate.
Printers and Plotters: It is recommended that all printers utilize laser technology and be capable of processing the industry standard page description language, PostScript, or the HP PCL Level 5 printer control language. These will provide the ability to print electronic information generated by nearly all software packages on all printers at the University.
A high speed, high capability, networked production printing capability is required whereby users can submit electronic documents over the network by completing an on-line specification for the print job.
Optical Scanners: Optical scanning can provide several benefits for information systems. It reduces the need for keying data that originates in paper form. It permits the electronic acquisition of data and documents that contain graphic and image information. It permits the use of digital technology for the archiving of data and documents in an efficient and effective manner.
Bar Code Technology: The use of bar code technology to identify University assets, including documents, is recommended. Bar code technology is currently used by the library system to track their information assets. Other assets are also identified and tracked using bar code technology. This should be extended to other assets where it is cost effective.
Adaptive Technology: In order to provide handicapped individuals with the same access to information and functionality as others, adaptive technologies for computers must be part of the system. The use of large print, Braille, voice synthesis and voice recognition must be available for those users who have a need for such capabilities.
Storage: As more and more data is acquired electronically and as a larger proportion of that data becomes images, voice, and video, the demands for electronic storage will continue to grow at a fast rate. The increased capacity and speed of optical storage technologies such as WORM (Write Once, Read Many) and optical jukeboxes will satisfy this need. The acquisition of packaged information on CD-ROM's (dictionaries, encyclopedias, almanacs, journals, books, vendor catalogs, etc.) requires that CD-ROM devices must be available and network accessible.
(next) or 
(previous)
Introduction
Framework for Building Information Systems
Philosophy and Principles
Architectural Overview
Summary
or
(Return to Reshaping the Enterprise: An Overview)