Constructing and Deploying Campus Portals in Higher Education

INTRODUCTION

A portal is a doorway, a gate, or a means of entrance. For example, the local library is a portal for knowledge. In this age of the Internet, portal refers to a Web site that offers a broad array of resources and services, such as e-mail, forums, search engines, and online shopping malls (Webopedia, 2005). Like any project, portal development should observe the system development life cycle guidelines with activities including planning, analysis, design, implementation, and support. Launching a portal requires careful planning and strategiz-ing. Analysis defines a portal’s requirements, determining its content and functionality. Design selects the appropriate software, platform, and architecture. Implementation makes the “build or buy” decision. Support is to maintain the portal, provide support, and perform upgrades.

FROM COURSEWARE, ERP TO PORTAL

The evolution of online technology in higher education has come a long way from courseware management, enterprise resources planning (ERP) to systems integration. Today, 83% of higher educational institutions in the U.S. regularly use course management systems. Besides network security, administrative ERP and system integration are ranked as the top campus technology priorities (Green, 2004). ERP systems provide tools for students, faculty and alumni to access and update academic and administrative data, making school services available real-time via the Internet. Proper deployment of ERP can streamline business processes. With increased productivity, the university can provide better services without increasing staffs. A campus portal is pivotal in integrating and the seamless offering of functions from administration, collaboration to courseware delivery.

Information technology expenditures for course management, administration and digital contents are huge expenditures in educational institutions today. The convergence of digital repositories and Web content management is an inevitable natural evolution for the future (Duncan, 2004). The Internet has made unprecedented impacts on the educational landscape. Along with more effective use of the valuable and expensive digital resources, faculty and students also have raised expectations. They demand access with simplicity and transparency in an increasingly complex environment.

The campus portal is a hub from which the campus community can locate all the commonly used Web resources. It simplifies access to controlled information, while providing a user-centric interface with personalized information to different constituents. Yet, the campus Web site is not the campus portal, and the campus portal is not the campus Web site. While access to a Web site is anonymous, portal access requires authentication and different users will have different needs, interests, information access and authorization levels (Vincy, 2005). A portal is the centralized, but customized, focal point for varied audiences within the campus community.

Planning and Strategizing

A campus portal can be an effective channel for communication, collaboration, and transaction for different constituent groups, including students, faculty, alumni, and even business partners. Thayer (2002) defined software project planning as specifying the goals and objectives for a project; and the strategies, policies, plans, and procedures for achieving them. Planning is a two-step process: capturing requirements, and plans to deliver the product to the requirements. Delivering a successful product requires careful planning and strategizing, which is far from a simple or trivial process.

As information technology becomes more pervasive and dispersed across the campus, debates are renewed on the mission of an educational institution (NPEC, 2004). A university is made up of classrooms, residence halls, athletic facilities, library, and teachers. On another level, a university is less physical. It is an embodiment of activities that organize and facilitate learning, and bestow degrees; and many of these activities can be provided via a virtual setting. In fact, most institutions are somewhere in between “bricks to clicks.” Many are in the process of determining the right mix between the extremes. Where an institution perceives itself along this spectrum is likely to determine the mission critical activities that must be supported by its campus portal.

The most important task in deploying a portal is ensuring its widest adoption possible. After all, the usefulness of a service is determined by the breadth of its user and the frequency of its usage. Just like any e-commerce portal, universities must carefully consider strategies that garner and retain a thriving user community (Bansler, Damsgaard, Scheepers, Havn, & Thommesen, 2000). Kuh and Whitt (1988) defined culture in higher education as the collective, mutually shaping patterns of norms, values, practices, beliefs, and assumptions that guide the behavior of individuals and groups in an institute of higher education, and provide a frame of reference within which to interpret the meaning of events and actions on and off campus. A successful portal must be customized to the institution’s unique culture. It should align students, faculty, and alumni to the institution; enable the dissemination of targeted information to appropriate audiences; and help to foster and build the campus community. Above all, a portal is a service rather than just a product. Proper portal planning should include quality assurance, training, upgrades, feedback, and support for the campus community within the institution.

Requirement Analysis

Requirement analysis addresses both the campus portal’s definition and its acquisition process. Requirement definition of the portal should be focused on delivering high-quality and personalized functions based upon a profile created by individual users. The portal should be a vehicle that provides all of the tools different constituents needed on a daily basis in one general area. Strauss (2000) listed several mandatory features of a campus portal: personalization, search, channels, and links; and desirable elements such as customization, role-based models, and workflow.

In general, a portal should have a single secure log-on procedure. Users should be able to define and select channels, search contents; and to access chat rooms, message boards, and personal e-mail. For prospective students, they should be able to submit and track admission, scholarships, and financial aid applications. Current students should be able to view the course catalog, schedules, and register; check account balance and pay bills; submit requests for campus resources; communicate with peers; read announcements, news, and headlines; and change personal information. Faculty should be able to post course material and grades, view schedules and rosters, and conduct other administrative tasks. For alumni, the portal should assist them with continueing to be a part of the campus community, keeping in touch with events, staff, and faculty.

Regardless the portal is used to support learning and collaboration, course delivery or daily administrative functions, planning starts by defining the mission critical activities that need to be provided online. Furthermore, the value of these activities should be concrete and well defined. Can the portal really improve efficiency and productivity? Can it provide better value and added service to the users? What institutional goals can be achieved by exercising the e-business model? Are these requirements valid, or are they hypes and we are reacting to the “me-too” syndrome? It is most crucial to have a clear understanding ofthe business value of the portal. A clearly defined value helps to justify continued project expenditures, and obtain consensus amongst different constituent groups.

The requirement acquisition process should start from top down with several deliverables breaking down into business, technical, and creative requirements, deriving in a logical sequence (Quirk, 2002). The process should be designed to answer the key questions: Who are the users? What functionality does each constituent group need? What content is available, and what more is needed? How does one define quality and how will one measure the return on investment? Projects that do not start out with a big picture view usually languish or provide only marginal value to the organization.

The analysis process focuses primarily on business requirements, as technical and creative requirements play only a supporting role. A portal will only provide as much value as the function and content delivered through it. The required functionality and content should be identified and cataloged; and this process will be most time-consuming and must be thorough. Based on business requirements, technical requirements can be concluded via the selection of portal tools and platform. Finally, creative requirements define user experience: the look, feel, and usability of the portal. Other issues that should be determined during this stage include the quality assurance plan, logistics for training and rollout, user and content maintenance, and the security policy. With a clear vision, and well-defined needs, the university can create a portal embraced by all constituents. Proper planning based on needs and priority enables the project to reach beyond its initial phase, leading to smooth implementation without costly changes in direction at midstream.

Design and Architecture

Web architecture follows a multitier model that evolved from the traditional two-tier client-server model. In a mul-titier architecture, a middle tier is introduced to essentially create a client-broker-server connection. In typical three-tier architecture, the front-tier is a user interface layer. The middle-tier acts as an intermediary allowing clients to access different backend resources, and pull together information from disparate systems. The back-tier interfaces with business applications, databases, content repositories, and search engines (see Figure 1).

The component interface between and within tiers should be platform independent and interoperable. The front-tier interface should be implemented using extensible HyperText Markup Language (XHTML), Javascript, Java applets, and extensible Markup Language (XML). Communication between tiers should be implemented using Web service, service-oriented architecture (SOA), or .NET type framework. With rapid convergence of Web standards, design and architecture have become less an issue in campus portal development. This section is intended only as an overview. Detail coverage on the subjects and other technical issues are discussed in many other articles in this encyclopaedia.

Figure 1. Multitier architecture

Implementation and Alternatives

The build or buy dilemma has existed in universities as long as campuses have had computers; the debate is renewed every time when a new information technology initiative is proposed. Campus portals are a mandatory facility in today’s competitive and technologically driven higher educational market, as perspective students and faculty demand wired campuses and convenient Web access. Buying software from outside vendors costs less than in-house development. Sometimes, building in-house is the only way to meet the institution’s special needs. Most likely, universities need to take an integrated approach: buying what are the best available for specific tasks, then hiring developers to combine the components into a single unified system (Olsen, 2000).

The Build Option

The most common argument for an in-house solution is that institutional need is uncommon; either the functionality is unique, the interface is too complex, or the time needed to integrate a package solution takes too long. For developers choosing the build option, uPortal (http://www.uportal.org) is a free, sharable, open source and open standard system that is built upon Java, XML, and Extensible Style Language (XSL). The system is a collaborative effort among several of the JA-SIG (Java in Administration Special Interest Group, http://www.ja-sig.org/) members, which include Princeton, Yale, and the University of Delaware.

uPortal is a framework for building custom portals that enable universities to integrate Web-based applications through an open Java framework (Gleason, 2001). The current release of uPortal is version 2.5. Applications can be added either via custom Java channel loaded into the uPortal framework, or as a Java servlet that outputs XML installed as an XML channel. Existing Web-based applications can be integrated as Web proxy or XML. Custom applications can be implemented into the uPortal framework using Java wrapper calling methods. Naturally, open source products do not offer the same level of support as commercial software, though consulting firm support is available. Furthermore, uPortal also requires a very high level of expertise in Java, XML, XSL, Structured Query Language (SQL), and XHTML. Customization depends heavily on local knowledge. As the product canbe deployed on different platforms, its scalability is difficult to evaluate. The absence of integrated redundancy, failover, and backup capabilities are another short coming. Finally, cost is always an important consideration. A portal’s cost is not just in hardware, software and infrastructure. The cost also includes staff and management, maintenance and upgrade; and integration of the institution’s existing information services into the new portal.

The Buy Option

Even well-funded universities are finding it challenging to keep pace with the rapidly changing technology, though abandoning the “not-invented-here” mentality can be difficult. But universities no longer code their administrative or library systems. Networking software today is mostly commercially acquired. In lieu of building a portal from the ground up, there are many commercial products available that can be customized for use in creating the campus portal. The technology has matured, making these products more attractive and appropriate to many academic institutions.

Most institutions elect to buy over build, as enterprise portals are currently the most cost-effective solution available (Zastrocky & Yanosky, 2002).

There are plenty of commercial products with varying levels of customization and support, including portal vendors such as Jenzabar (http://www.jenzabar.com), e-learning vendors such as Blackboard (http://www.blackboard. com), and ERP vendors such as Peoplesoft (http://www.peoplesoft.com). Portal vendors often follow a strategy of gaining access to the campus community via partnership, then generating revenue via advertisement and targeted marketing. The vendors deploy and manage the customized system, which greatly lowers capital investments and resource constraints placed on the institution. Apart from issues of control and security, it is always a delicate balance to maintain institutional integrity while provide adequate revenue for the vendors. Naturally, aligning with too many things that do not reflect academic rigor is inappropriate for an institution of learning.

Traditional e-learning vendors have the primary expertise in online course management. They also recognize the need for schools to integrate their administrative processes. While remaining focused on distance learning, they develop integrated portal solutions that interface with other major ERP systems. ERP vendors, on the other hand, have expertise in administrative systems. Their portal solution strategy is to extend Web-enabled services to the campus community that are critically dependent on data from the administrative systems.

Vendor products provide a tighter integration with internal data sources. They are designed to work well when implemented as a total solution at predictable cost, but they are expensive and tied to the vendor’s, not the university’s agenda. The enterprise software market is currently working to define and deliver the next generation of applications that uses Web services and other emerging standards. For these new products, the promise is ahead of reality and the future is far from definitive. A cautioned approach is therefore strongly recommended (Greenbaum, 2003).

Selecting Alternatives

In this period of rapid technological innovation, there are many varieties of portal service offering in today’s marketplace, each holding a unique niche. When evaluating the “buy or build” alternative, the decision maker needs to examine industry trends carefully, ensuring the solution can address both the present and future needs of the institution. As a general rule, strategically important and core value applications should be developed in-house. The selection process is a matter of balancing resource constraints, on-going support, technical competencies, and enhancement requirements against issues such as time to market, competitive advantage, and support for current and emerging industry standards (Po, 2002). Decision analysis is straight forward and can be done by comparing strengths and weaknesses of tangible criteria using a rubric. Rubrics are popular tools for assessment and evaluation in the field of education. A rubric contains three basic components: a desired goal; elements that need to be performed to achieve the desired goal; and measurements for acceptable and unacceptable performance (see Table 1). A weighted score system is usually adapted to make important elements stand out (Frazee, 2001).

Technology alone cannot solve an institution’s problem. Business process and campus culture must also be reengi-neered, and the institution itself has to change, rather than just the software (Gage, 2004). Regardless of build or buy, the portal is likely to require integration with other components. Integrating new systems with old processes will take time and money. The university must also cope with version upgrade gridlock, as upgrade by one vendor renders the other systems in place unusable. The interruptions will cause service delay, budget overrun, and unhappy constituents. The project manager should always plan the portal project carefully, and expect the unexpected.

Table 1. A rubric with goal, element and criteria

Maintenance and Support

Successful portal deployment involves creating a long-term operational model with adequate capacity that addresses ongoing product upgrades and needed technology changes. Emphasis must be placed on continuing staff skills acquisition and enhancement, so that the institution can leverage tools and technology to effectively address and resolve issues within the portal. The information technology group must address the issue of applying required patches and upgrades, and capacity enhancement, should server and bandwidth requirements become overloaded. As with all projects, the public launching of a campus portal will be followed by high initial expectations. Consequently, the information technology group will need to develop and implement sound strategies and solid 24×7 support mechanisms to ensure expectations are consistently met and exceeded. A good portal helps the campus to move toward community building. Its effectiveness ultimately depends on how the portal addresses information needs of its users and sponsors.

CONCLUSION AND FUTURE TRENDS

Just as the dot.com boom was replaced by a more circumspect approach to e-commerce. The campus portal market has retrenched, with revised business plans, demise of some providers, and consolidation of others. Should the university deploy a campus portal? The decision is really individual, depending on the institution’s technology needs, funding resources, strategic priorities, and the continued evolution of the solutions available. While the initial craze that promised something for nothing and delivered far less than expected has passed, campus portals are far from demising. It will remain a promising solution to organize and electronically connect the campus community, both today and into the future.

KEY TERMS

Bricks to Clicks: An e-commerce strategy by which a company attempts to integrate a traditional physical business with an online presence.

Courseware: Software designed to be used in an educational program that supplements or replaces traditional course activities.

Enterprise Resources Planning (ERP): Management systems that integrate various facets of business operations.

Open Source: Programs where the source code is available to the general public for use and/or modification from its original design, free of charge.

Proxy: A server that sits between a client and a server. It intercepts the requests to see if it can fulfill the requests itself or forward the request to the real server.

Servlet: A small program that runs on a server. The term usually refers to a Java applet that runs within a Web server environment.

System Development Life Cycle (SDLC): A systematic approach to problem solving and developing information systems.

Systems Integration: The implementation of a computing solution by connecting different systems in an existing infrastructure so that they can work together.

Wrapper: A piece of code that allows classes to work together by bridging the incompatible interfaces. It acts as an interface between caller and the wrapped code.