Five years ago, Howard Frank joined the University of Maryland’s Robert H. Smith School of Business as dean. He had recently ended a four-year tenure with the Defense Advanced Research Project Agency, which invented the technology that became the Internet, and the wide-eyed technologist was looking forward to his next challenge: He wanted to make the Smith School the premier technology-oriented business school in the world.
“We had the raw material here, and I had the support of the president of the university and the faculty,” says Frank.
To reach his lofty goal, he rejiggered the curriculum so that it now emphasizes courses in e-business, supply chain management, business process integration and global knowledge management. He also hired a slew of new instructors — 55 in the past four years.
While the curriculum shifted in response to the business world’s need for tech-savvy graduates, the school’s IT infrastructure remained a relic of the past. It was ironic that a business school trying to turn out tomorrow’s tech leaders should be hobbled by such a dated system.
The fact was that the school lacked the proper infrastructure to support its 3,500 students and faculty on both its main campus in College Park, Md., and at its satellite campuses in Shady Grove, Baltimore and Washington, D.C. Users on the satellite campuses could not get the same level or quality of access to applications and systems that students on the main campus received. And students and faculty on the main campus could run applications only from a networked PC; they could not access the Smith School’s systems remotely.
“We have large financial databases that our faculty in the finance department uses,” says Sandor Boyson, the Smith School’s effusive information strategy chief and director of its Supply Chain Management Center. “When they leave this institution at night, those [databases] are no longer accessible to them because they’re physically contained behind the firewall.”
In addition, students and faculty were forced to use e-mail to share ideas and edit documents, which created all sorts of headaches when it came time to synchronize document versions, never mind the tax it levied on the network.
Further complicating students’ lives was the problem of identities. Students had to memorize as many as 16 user names and passwords for each online course and for each system they used on a regular basis. They also complained that they didn’t have access to a centralized calendar and had to look in as many as four places to get information on social and academic events on campus.
To rectify those woes, the school invested several million dollars to create a Web-based portal — the eSmith Web Portal — where students, faculty, staff and external partners such as alumni, other academic institutions and businesses can access all the services, research and applications they need to manage and register for classes, post and read syllabi, download white papers, participate in online classes, and share research.
“With the portal, you log on once, it recognizes who you are, it sends authorization to the systems you need to use, and you’re in,” says Boyson. “You can get documents on your shared drive no matter where you are as long as you have a Web browser and an Internet connection.”
The eSmith portal, which went live Oct. 1, is personalized for each user based on his preferences and role in the academic community. It also facilitates collaboration on research projects, and ultimately provides the foundation for the knowledge sharing that’s necessary to keep a business school competitive with, if not exceeding, the Ivy Leagues.
Origins of the Portal
The idea for the eSmith portal came from work the Smith School’s Supply Chain Management Center did with the state of Maryland and the U.S. Department of Defense in developing portals. Boyson says the experience gave him a good understanding of the benefits the Smith School could reap by launching something similar. His experience deploying online course management tools in the past, coupled with the school’s involvement in Educause (an association charged with advancing academia through the innovative use of IT), gave him an idea of the basic functionality needed.
Around January 2001, Boyson drafted a proposal for the dean outlining how the Smith School could use a portal. The tech-savvy dean approved, and Boyson gathered a core team of the school’s CIO and CTO, as well as a portalmaster, systems administrator and two application specialists, who began working on a prototype that fall.
Team members first created the basic infrastructure, which they borrowed from the eMaryland portal the Supply Chain Center had built. It consists of the university’s lightweight directory access protocol, or LDAP, server, which essentially functions as a directory of everyone in the Smith School community and which allows portal users to get customized views of content and access to applications based on who they are. A portal server from iPlanet (a Sun Microsystems Inc. product) provides security. There’s also an application server from ATG and an Autonomy search engine. The application and portal servers run on hardware and software from Sun Microsystems; Oracle Corp. provides the back-end databases.
Those vendors were chosen because they offer products that are Web-centric, based on open standards, interoperable with the university’s LDAP, and because they required minimal customization.
Once the core infrastructure was established, the development team surveyed and met one-on-one with department heads, faculty, staff and students about what they wanted to see in the portal. The finance department in particular wanted to make sure students could access databases containing historical corporate financial information often needed for assignments. Based on feedback, the team also added online course management, instant messaging and collaboration applications to the portal.
By February 2002, they had a beta version that one of the school’s e-commerce classes could evaluate.
Ernie Soffronoff, a graduate of the Smith School who now serves as eSmith’s portalmaster, says that most of the changes made were to screen prompts intended to guide the user from one page to another. For example, during the beta phase, the log-in page asked for a “user ID.” But the students often have more than one user name, and they didn’t know which to use. In the next iteration, the log-in screen asked specifically for the user’s university directory user name.
Usability testing of the portal involved making sure it could stand up to thousands of hits at a time. Since Sun Microsystems had already done a formal scalability study of eMaryland and since the Smith School was using the same architecture, the team spent only two days stress-testing eSmith.
Technical Challenges, Cultural Solutions
In adding collaboration and single sign-on applications to the portal infrastructure, the team ran into a spate of technical hurdles. They had to figure out a way to give external users, like alumni who aren’t in the university directory, access to the portal. Working with the university’s IT department, the team created subcommunities of users that can be dynamically generated within the LDAP directory to be recognized even if they are not usual Smith School members.
The biggest challenge was integrating the university’s siloed campus systems so that a user would automatically have access to all the systems. That meant the LDAP servers, HR, e-mail and student registration systems, and several others — which previously required separate log-in names — would have to recognize a single log-in from the portal. The development team wound up writing special code for each system to teach it to accept the portal system’s user names.
After that issue was cleared up, they discovered another one: system time-outs.
Each campus system had its own limit of how long an account could be inactive before a user was logged off. The portal could be inactive for 30 minutes, but the student registration system shut off after 15 minutes. “We had to make sure that the portal would honor the time-outs of these systems,” says Soffronoff. Again, the development team handled this case-by-case, adhering to the security concerns of each system.
During the process, the development staff, Soffronoff in particular, had to build relationships with the individual owners of each of the systems. “It was a little surprising to me,” says Soffronoff. “I spent far less time trying to figure out creative technical solutions than I did building the relationships and creating trust with the people who I needed to integrate the portal with. That was a harder task in most cases than any of the technical work that needed to go on for the integration.”
Vive La Diff
