This paper was presented at the 1997 CAUSE annual conference and is part of the conference proceedings, "The Information Profession and the Information Professional," published online by CAUSE. The paper content is the intellectual property of the author. Permission to print out copies of this paper is granted provided that the copies are not made or distributed for commercial advantage and the source is acknowledged. To copy or disseminate otherwise, or to republish in any form, print or electronic, requires written permission from the author and CAUSE. For further information, contact CAUSE at 303-449-4430 or send e-mail to email@example.com.
Dancing With the Devil:
Implementing a State-wide Web-based Advising System
L. Dean Conrad
The Florida Legislature mandated creation of a new state-wide student advising system called FACTS, Florida Academic Career Tracking System. This was intended to provide a key piece of infrastructure needed to support the state's distance learning initiatives. The intended audience is 1.5 million high school senior and post-secondary students. Legislators want students to be able to shop for degrees at the various state institutions, view their transcripts, check degree progress, and assess the impact of potential transfers or changes in major. The scope of the system involves 10 public universities and 28 public community colleges. Question: how do you create a single state-wide system that remains responsive to the different policies and needs of 38 separate institutions? Answer: implement a web-based distributed system that links to each institution's existing advising system and student data. Assignment: put up a working pilot for 3 universities and 5 community colleges in 90 days! In this paper we will discuss the design of the pilot, the challenges involved with implementing it, and the issues that must be resolved to deploy it state-wide.
During the 1996 legislative session, the Florida Legislature passed legislation requiring the stateâ€(tm)s 10 universities and 28 community colleges establish a statewide systems infrastructure that would allow post-secondary (and high school) students to access their transcripts, assess progress towards a degree, shop for degrees at the various 38 public institutions, and assess the impact of changing majors or institutions. In all, 1.5 million students could potentially utilize this system. This was seen as the first phase of a more comprehensive system that would also allow students to apply for admission, research financial aid options, register for classes, and (eventually) pay fees at any public institution from anywhere in the state and (conceptually) 24 hours a day, 7 days a week. The new system has been tentatively named FACTS, Florida Academic Career Tracking System.
In the state of Florida, public universities are governed by the Florida Board of Regents while the community colleges are governed by the Board of Community Colleges which are separately managed and funded entities. There is a mishmash of systems implemented at each state institution. The universities had a shared advising systems infrastructure called SASS, while the community colleges were just developing such an infrastructure at the time the legislation was passed. Each institution has implemented their own admissions, registration, financial aid, and fee payment systems. 23 of the 28 public community colleges have formed 5 different systems consortiums where all the institutions in a consortium share development and maintenance costs for a set of systems. The remaining 5 all run independent systems. With the mix of systems and architectures involved, the prospect of bringing all this together in some cogent fashion seemed daunting indeed!
Need for System
The reason the Legislature has taken an interest in this issue is because the projected increases in college age students over the next 10 years in the state of Florida is roughly 50%. These students are already in the pipeline. Florida has no state income tax plus a voter-driven initiative was passed a few years ago that limits new taxes and fees, so clearly we will not be building additional brick-and-mortar institutions to accommodate the projected growth. How many of these students will actually choose to continue their education after high school is unknown. However, it is reasonable to assume there will a significant--if not proportional--increase in demand for higher ed in the state, so the issue remains in how to deal with that increase, whatever it will be.
The Legislature has been working on this problem and has focused on two other trends: the trend for students to take 5 or 6 years to complete an undergraduate degree and the trend for students to take more hours than needed for graduation (clearly the two are related). Two state initiatives have been put in place to help improve the productivity of the existing higher ed system in Florida. One is the "out-in-4" program to encourage students to complete their college education in four years. The other is to begin charging full fare for "excess credit hours," that is credits beyond a limit of 115% of those needed to graduate. The classic carrot-and-the-stick approach. These initiatives will have a distinct impact on how long students linger in the system, however, it became clear these moves by themselves will not be enough.
The developing technologies associated with distance learning offer the promise of providing an alternative form and media for teaching and learning using personal computers and the world wide web/Internet. A number of states are looking at this option as a way to leverage their investment in higher education. The public is demanding many other services be provided within the boundaries of the existing tax structure, so the possibility of delivering instruction electronically without having to build additional brick-and-mortar classrooms and campuses is seductively attractive. The Western Governorsâ€(tm) University and California State University system are but two examples that have received much publicity in recent years.
The Florida Legislature is similarly interested in this possibility and it recognized the way to accomplish such a "virtual university" is to leverage the faculty and other resources at the existing 38 state institutions. In order to do this, however, we need a way for students to put together degree programs with pieces (potentially) from several different institutions. Much work has been done to streamline the ability of students to transfer credit between institutions, e.g., a common course numbering system and acceptance of a community college AA degree as meeting all university General Education requirements. Further work will be needed, but we can leverage these agreements to support the desired goal. A basic need will be the ability of students to easily research and pursue options at the existing institutions. Hence the interest in a statewide student advising system.
90 Day Pilot
Planning began in earnest for the new system the summer of 1996. No clear project ownership was assigned, however, the Board of Regents (BOR) hosted several focus sessions in July/August with the intent to nail down user expectations/requirements and surface technical options to accomplish a pilot implementation. Early on, it was decided that a web-based delivery system would be desirable. A number of existing systems at different institutions were considered for their potential to serve as a basis for the statewide system. These each had some interesting and innovative characteristics and one existing system was sufficiently comprehensive to provide all the desired functionality. However, it was implemented on a central mainframe and there was considerable opposition by individual institutions to turning over responsibility/control for their data and business rules. It became clear that a distributed systems design would be the appropriate solution.
Ownership of the pilot project was resolved with that assignment falling to the Secretary of the Department of Management Services (DMS). The reasons for this assignment was that DMS was responsible for the stateâ€(tm)s communications infrastructure plus the Secretary was a member of a new state entity formed to foster and coordinate distance learning activities in the state: the Florida Distance Learning Network (FDLN). FDLN had been appropriated ~$15M in FY97 for distance learning programs. The FDLN Executive Board felt this project was sufficiently important as to warrant funding off the top. It was deemed crucial to have something to demo by the start of the 1997 legislative session, so DMS hired a number of consultants to make that happen. By the time the requirements were articulated, the design characteristics chosen, pilot participants identified, and the consultants hired, there were only 90 days remaining to the start of session. The pilot project officially began on December 1, 1996 with a target completion of March 1, 1997.
The first major task was getting the committee to agree on a model for systems design. We discussed four basic approaches (see Table 1). Considering the time frame allowed for this pilot and reticence by the various institutions in giving up individualized control over business rules and data, the committee decided to implement Model 4, distributed processing with distributed data. This allowed us to build on existing system applications to minimize development time and costs while maximizing and leveraging current institutional investments. The university system had invested time and dollars in their state-wide Student Academic Support System (SASS) for advising. The community colleges were in the process of developing their own advising systems. The scope of the prototype was limited to advisement functions: displaying transcripts and degree audits, degree shopping, and displaying a degree audit for a transfer student from another institution. Other functions intended to be incorporated in addition to advising are admissions, financial aid, fee payment, and registration; all with e-mail capability.
To interface to the individual student data and advising systems, we decided to use a common electronic data interchange (EDI) format to transport the required data from each institutionâ€(tm)s databases to the server. The State of Floridaâ€(tm)s FASTER format (a predecessor to the national SPEEDE format) for exchanging transcript data was chosen because that format was already being processed by all institutions. This decision saved a considerable amount of time. We extended the FASTER format by adding messaging codes, so the server software could recognize what kind of request was being transmitted. Those codes told the server how to present the data back to the Webâ€"in transcript or degree audit format.
The server software acted as a router to send the input request to the desired institution, gather the necessary formatted data, and send the data to the requested destination for processing. The processed data was returned to the server in the common format to be formatted for display back to the studentâ€(tm)s web-browser.
The following summarizes design characteristics for the overall design of the pilot:
* the interface for the students would be a web browser--Netscape 3.0 or better;
* the system would interface to each institutionâ€(tm)s existing advising system and data--local control of data and business rules;
the stateâ€(tm)s existing FASTER format would be used to exchange student transcript data;
* there would be a common format for all web pages and generated responses;
* some standard EDI format would be needed to request a service from an institutional system and for them to respond;
* student social security and Personal Identifier Number (PIN) information would need to be encrypted to maintain security;
A technical committee was formed with representatives from the community college and university systems, the Department of Education, and Board of Regents. This committee was to identify uniform standards, develop a system prototype for a state-wide information system with concentration on academic advising and degree tracking, and prepare a budget for replication of the prototype to all 38 public institutions. The Internet was to be used as the delivery mechanism...and we had only 90 days to do this.
The institutional participants in the state-wide pilot needed to be a combination of institutions from the community college and university systems that would be a representative sampling of different architectures and hardware platforms. We had the following volunteers from five of the twenty-eight community colleges, and three of the ten universities:
* Brevard Community College; and
* Florida State University;
* Manatee Community College.
* Miami-Dade Community College;
* Pensacola Junior College;
* Santa Fe Community College;
* University of Florida;
* University of Central Florida;
Due to the varying levels of in-house expertise and available staff resources, consultants were hired to assist in overall project management, web server code development, storyboard development for web-browser presentation, and interfacing between the server and the host applications.
Some of the institutions already had web applications in various stages of production that had been demonstrated to the legislative staff and technical committee. The committee was instructed to take the best of each system and use that as a system design for the prototype.
Problems experienced early on stemmed from a lack of organization among the many participants. There were a number of false starts by institutions, task assignments were not clearly assigned at first, and communications between institutions and vendors were not clear and up-to-date. By January--with the clock ticking-- the project manager had begun to organize the committee and move the pilot forward. To facilitate organization, a news server was established to keep everyone current on updates on project status, time lines, and participant comments.
Site visits to the pilot institutions were conducted by the consultants to determine the hardware and software configuration needs for those participating in the project. Decisions for how to interface with the server were based upon those visits. Hardware was supplied or upgraded where needed and network interface software was provided.
In order to meet our deadline, we had to set project limitations. We concentrated on proving the functionality of the prototype, not necessarily solving all of the standards, data accuracy and policy issues associated with a project of this scope and nature. Standards for processing transfer work, course equivalencies, student exceptions, data security, system down time, and data standards were added to a list of issues to be addressed later in the production implementation of the system (see below).
The architecture of the prototype involved several different types of hardware and software configurations. This allowed us to assess some of the different ways to integrate the institutions. The central server was a SUN Enterprise 3000 System (UNIX) located in a consultantâ€(tm)s office in Tallahassee. The institutional host processors that housed the student data were UNIX, AS/400, and IBM Mainframe and were located in Tallahassee, Gainesville, Orlando, Miami, Pensacola, and Cocoa. The networking interfaces from the hosts to the server were IBMâ€(tm)s MQ Series, TCP/IP socket connections, or IBMâ€(tm)s DB2 Distributed Relational Database Architecture in conjunction with HTTP. The HTTP server software was Domino and Java. The Web presentation used hard-coded HTML to allow for full printing of documents sent to the display.
After the pilot was completed and demonstrated to the legislative staff, a short survey was sent to a limited number of faculty, staff, and students. Their comments and suggestions for improvement were added to the list of issues to be considered for the production implementation. The pilot participants also evaluated the overall project to summarize problems and successes encountered and policy issues to be resolved before production implementation. These technical and policy issues are outlined in the next section.
Issues For Full Deployment
Given the pilotâ€(tm)s short fuse, we were not able to address all needs or resolve all problems. The following key issues have been identified for resolution in the full implementation.
Accuracy of results. The system needs to provide accurate and reliable results. A student needs to get the same "answer" whether receiving a degree audit from FACTS or from her/his home institutionâ€(tm)s degree audit system. A potential student also needs to get the same answer when degree shopping at a new institution using FACTS and when he/she applies for transfer to that institution. There are a number of factors that can affect the outcome of an audit and each institution handles these in slightly different ways. These factors include:
* credit from prior institutions--including out of state and/or international;
* remedial course credit;
* grades, credit hours, and quality points earned;
* credit hours attempted with hours and reason for non-completion;
* semester/quarter hour equivalency;
* identification of completion of General Education requirements;
* identification of completion of an AA;
* identification of AP, IB, CLEP credit awarded/attempted; and
* identification of completion of Gordon Rule, Foreign Language, CLAST, SAT/ACT/GRE.
Security of information. Adequate privacy for student data must be addressed and acceptable security minimums need to be specified. We need to find a balance between full encryption and simply displaying a message box notifying the student the transmission is not secure. What about capturing student information at an institution being "shopped" for marketing purposes?
Common output format. With 38 institutions generating output, we need to provide a common "look and feel" to the response. This includes:
* specifying semantics--ensuring the same words are used for the same things;
* disclaimer information;
* the data elements being returned;
* presentation of summary and detailed information;
* separators between sections;
* use of upper/lower case and font; and
* location of information on the screens.
Deployment strategy/timeframe/budget. A detailed plan for implementation is needed that addresses:
* projected transaction volumes;
* target response times;
* specific configurations at each institution;
* specific support needs at each institution;
* stress testing;
* budget requirements;
* milestones for deployment; and
* ownership of the overall system.
Further enhancements. A number of further enhancements were identified from the pilot:
* scores and total points for standardized tests;
* probation status;
* methods for projecting what a student plans to have taken (e.g., assume an AA);
* link to course catalog;
* link to schedule of classes;
* link to e-mail for advisors or to get additional information;
* information on limited access programs;
* matrix format to show classes required by term;
* display all institutions offering a particular degree;
* help screens;
* admission criteria for each program;
* specify how common pre-requisite/co-requisite information is maintained;
* specify pre-requisite/co-requisite courses;
* color code the results on the display screens;
* all information presented in HTML format instead of text;
* allow multiple requests per "session" (one-time SS#/PIN entry); and
* provide a method to capture and analyze usage statistics.
Two committees have been formed to develop an implementation plan and budget for state-wide deployment of this system. The policy committee will address the educational standards and policy issues that must be resolved. The technical committee will address the hardware, software, data, technical standards, and connectivity issues. These two groups are also looking at subsequent phases. For instance, a number of institutions already support admissions applications and course registration via the web. We intend to link to these in the short-term to expand the scope of delivered functionality.
Development of the budget will be a combined effort of the two committees, but a very rough initial estimate is in the $6-9M range for full state-wide deployment.
The specific schedule for deployment will be worked out as part of developing the overall project plan. However, there is a need to remain time-sensitive on this project. We are very aware of the need to have "something" in place by the beginning of the 1998 legislative session.
This project is notable because of itâ€(tm)s scope. The goal of deploying a state-wide system to provide advising, admissions, financial aid, registration, and fee payment for 38 state institutions serving 1.5M students is ambitious to say the least. The complexity, risks, and politics involved if we were to try to provide this in a traditional manner with a centralized mainframe system are self-evident.
The pilot project was a high-profile, somewhat chaotic proposition all the way around. There were many different constituencies involved: at various times the 8 pilot institutions, the Board of Regents, the Board of Community Colleges, Legislative staff, Department of Management Services, the Florida Distance Learning Network, the Department of Education, and the Governorsâ€(tm) Office. Not surprisingly, the technology was at times overshadowed by other issues and concerns.
The resulting design--distributed processing with distributed data--appears to be solid and one that can be extended to deliver all the intended functionality. This project may be a good example of the old maxim, "a good idea will out." Despite the various viewpoints, perspectives, preferences, biases, politics, and agendas, we have settled on a technically sound and supportable system. Much work remains to be done, but we do not see any "show-stoppers," at this point. When we achieve full deployment, we will provide the stateâ€(tm)s post-secondary and high school students a powerful and pervasive tool for planning their educational futures while building an important piece of infrastructure needed to support distance learning in the state of Florida.
|Table 1: Model Explanations|
|Model 1: Centralized Processing with Centralized Data||This model places all data for the 38 institutions on a single computer that would also contain the advisement applications. With this model, student transcript data is submitted by an individual student and processed against a central repository of program and graduation requirements from each of the 38 institutions.|
|Model 2: Centralized Processing with Distributed Data||This model contains a centralized advisement application along with the data stored at each of the individual institutions. A central computing site would be established at a large computing facility where all of the processing would take place. Data would be maintained at each institution.|
|Model 3: Distributed Processing with Centralized Data||In this model, each of the 38 institutions has their own advisement application on a computer located within their institution. They would access a central repository that contains information about other institutionsâ€(tm) degree programs.|
|Model 4: Distributed Processing with Distributed Data||In this model, processing takes place on the institutionâ€(tm)s own computer system with their own application processes and data. Interfaces to other institutionsâ€(tm) data utilizes an EDI format via a web server.|
About the Authors
Larry Dean Conrad is Director of Administrative Information Systems at Florida State University. He has prior experience as Director of Academic Computing and Director of the Computer Center at Arizona State University plus 15 years experience in business data processing in the private sector. Mr. Conrad has been active in the CAUSE organization and is presently a member of the CAUSE Board. He is a past Chair of the Editorial Committee for the CAUSE/EFFECT journal and was on the Program Committee for the CAUSE92 conference. He has presented and published on a variety of technical and managerial topics. Mr. Conrad has an M.S. in Computer Science from Arizona State University and a B.S. in Computer Science from Iowa State University and can be contacted via e-mail at firstname.lastname@example.org or via phone at (904)644-0066.
Linda Thanasides is Associate Director of Standard Software Development Services, a department of the Florida Board of Regents for the State University System. She began a data processing career 31 years ago in the telephone industry, and moved to the education field 20 years ago. Her experience ranges from data entry operator to manager of programming staff. Ms. Thanasides has a B.S. in Information Management Systems from the University of South Florida and can be contacted via e-mail at email@example.com or by telephone at (813)974-2525.