Copyright 1997 CAUSE. From CAUSE/EFFECT Volume 20, Number 1, Spring 1997, pp. 52-53, 56. Permission to copy or disseminate all or part of this material is granted provided that the copies are not made or distributed for commercial advantage, the CAUSE copyright and its date appear, and notice is given that copying is by permission of CAUSE, the association for managing and using information resources in higher education. To disseminate otherwise, or to republish, requires written permission. For further information, contact Julia Rudy at CAUSE, 4840 Pearl East Circle, Suite 302E, Boulder, CO 80301 USA; 303-939-0308; e-mail: [email protected]

Student Telephone Self-Activation at Boston College

By viewing individual communication services (voice, data, cable) as strategic tools in a communication infrastructure, Boston College was able to create an electronic communication environment with superior services at drastically reduced cost levels. This project received the 1996 CAUSE Award for Best Practices in Applications.

Boston College (BC) has sought to build a strategic communication infrastructure that would foster the free and open exchange of ideas among university constituents. To that end, a major network development project was established to deliver voice, data, and cable television access to every bed on campus and to all campus departments and classrooms.¹ This project was dubbed Agora, after the ancient Greek "agora," a gathering place that was central to Greek society.

Prior to BC's Agora project, the existing environment did not support data or cable TV services to any residence hall. Phone service was limited to one line per suite, which precipitated the usual monthly squabbles over long distance charges. This service was provided by NYNEX, whose activation and local charges proved costly to student subscribers.

During Agora planning, the university realized that the successful creation of a modern-day electronic "agora" would depend as much on user participation in these services as it would on proper network capacity planning. The enormous benefits to be gained from universal access to the agora and the administration costs inherent in providing elective services prompted BC to implement each of these services in a non-elective manner.

Given the task of delivering these universal services at a minimal cost to the university and its student body, the Office of Information Technology (OIT) and the University's finance division developed an implementation funding model with three main postulates:

• Boston College must own the infrastructure. While various vendors were willing to fund the physical construction costs in exchange for ownership of the service, BC would not sell its future for the sake of expediency. Long-term cost/benefits of owning the infrastructure justified the large capital startup costs.
• By consolidating administrative and student long distance traffic under a corporate long distance dialing plan, Boston College could reap savings from high-volume discounts from its long distance provider. BC could charge students highly competitive rates for long distance service and still have surpluses approaching the infrastructure loan repayment costs. BC could deliver all three services (voice, data, and cable TV) at little additional cost per student.
• No additional human resources would be allotted to administer these new services. OIT would highly automate service administration to satisfy this requirement.

Voice services implementation

Two possible implementation models became apparent.

(1) BC could pre-assign phone numbers permanently to jacks. The corresponding switch activations and voice mailbox creations could be done in advance. This choice would be straightforward to implement, but it has many shortcomings:

• The student's phone number would change with each bed relocation.
• Directory assistance request volume would remain high.
• Voice mailboxes would need to be manually deleted and recreated between occupants to reset the box.
• Security concerns arose over mapping numbers to locations.
• BC would either have to extend room assignments to the bed level or rely on student self-reporting for phone number data collection.

(2) BC could pre-assign phone numbers permanently to students and process switch changes as students move to a new locations. This alternative has compelling customer service advantages:

• A single number provides continuity of service for students over their entire stay at BC.
• Timely printed directories would drastically reduce directory assistance requests.
• Voice mailboxes established upon admission could remain accessible throughout each student's academic career.

There is one major disadvantage to this approach. Every student bed relocation would require that several switch commands be processed to relocate the student's phone. If students were allowed to retain bed selection privileges, these commands could not be processed in advance. Huge backlogs of service activations would build at a time when existing resources are already stretched beyond their limits. Would a permanent number be as valuable to students if they had to wait weeks for phone activation?

If BC could overcome the problem of the latter model, the results would be far superior to the former. This problem is basically a clerical data entry bottleneck. From a business perspective, the solution to this type of problem is to distribute the data entry to the consumer. In this particular case, the hurdle was the technical implementation of the solution, given that switch automation was uncharted territory. BC took on the challenge for the substantial end reward.

Immediate focus was given to switch interface automation. Although BC pressed the vendor for access to more intelligent switch interfaces, none was uncovered nor did the vendor pursue this with the university. The vendor did, however, provide us with C language code for terminal emulation to the switch. Automated switch access was a linchpin to BC's plan, so this code had to suffice. With extensive modifications, we ported this Sun-specific code to our AIX environment. We then developed automated terminal session code that replaced operator command line input with file input. With this major technical milestone accomplished, the application structure could take shape.

BC developed mainframe databases of phone numbers, jacks, switch ports, and wiring connections. Application procedures were developed to maintain switch data elements and their interrelationships. These procedures generated the appropriate switch commands to propagate these data relationships within the switch. IBM MQSeries message queuing was used to deliver commands to the RS/6000 and trigger the procedure to process these commands at the switch.

From early on in the project, the switch became the slave of the mainframe application. The application also helped to tightly control construction activities. Mainframe reports served as construction wiring blueprints. Extensive post-construction testing validated each jack for basic functionality as well as application meta-data accuracy.

CICS transactions were developed to effect student-phone-to-jack assignments. These transactions, like other application components, update mainframe databases and transmit the appropriate commands to the telephone switch. They were the early means by which student phone activations were performed. However, CICS transactions would not be the mode for distributed student phone data entry. Instead, BC developed an IBM Direct-Talk/6000-based voice response application for this task to simplify customer interaction and to eliminate the possibility of data inaccuracy.

One might wonder how a voice application could be used to activate a dead phone line. In actuality, all lines were already active. BC pre-activated every jack with campus-only dialing privileges under a software number known to the mainframe application. When the student dials the interactive voice response (IVR) application, it receives this software number and can thus determine the exact jack location. The student is then prompted to enter his or her ID number and PIN. Once authenticated, the student chooses the activation option and within minutes his or her phone number is activated at the jack from which the call originated. This IVR application provides a front end to CICS transaction logic, so code is not duplicated and transactions remain as a viable backup alternative in the case of IVR failure.

Long Distance

BC uses MCI as its long distance provider. MCI polls the BC switch daily to collect and cost call-accounting data. It also functions as BC's phone billing and collection agent. Each student receives a monthly personalized bill of long distance charges. All other Agora services -- local phone service, voice mail, data access, e-mail, and cable TV -- are provided free of charge from BC.

Voice mail enhancements

Mainframe procedures refresh common lists such as class rosters and department lists on a regular basis. Authorized individuals can log into voice mail and send a message to one of these lists by number. Gone are the days when faculty had to build and maintain their own class distribution lists. In addition, other mainframe procedures select individuals who meet specific criteria and automatically send a pre-recorded message to the selected group. A simple example is that we now can automatically notify students of overdue books by voice mail. The applications for this utility seem endless.

Conclusion

Acknowledgments

Endnote:

Back to the text

David McCormack ([email protected]) is Assistant Director of MIS at Boston College, where he focuses on application infrastructure and systems integration.