IT Architecture Team Report:
Portals

Executive Summary

This report represents a summary of the process the task force has used to investigate portals, as well as our short term and long term strategic recommendations for portals at Princeton. The charter for the task force is included at the end of this document.

We embarked on three separate tasks to accomplish the goals of our charter:

• Portal Definition
• Current Inventory
• Guidelines and Recommendations

In trying to determine the potential value to Princeton of an enterprise portal, we arrived at a simple, common definition and identified potential focus groups and methods of outreach we could use. At the same time, we had several conversations with other higher education institutions about their portal efforts, and had three Gartner interviews. We never took the formal steps of outreach at Princeton, because by the time we reached that point in the process we were convinced an enterprise portal was not a good idea.

At the same time we took a close look at what existed on campus, including true portals and websites that were portal-like. We looked at upcoming requests for portal-like information, and where we were headed with initiatives like administrative self-service, as well as increased functionality on the academic side.

Lastly, we determined some architectural guidelines we could employ in the present that would help us in our future efforts. We separated our short term and long term goals and thought about the best use of our current resources.

The most interesting and surprising result of this work was the evolution of our thoughts as we learned more. We started with the task of determining what the value of an enterprise portal would be to Princeton and how best to implement one. By the end of the study we had come to the shared conclusion that, for the short term, we should not pursue an enterprise portal at all. Although we all agree that an enterprise portal could add value in providing appropriate information to a person or group in a consistent manner, we see this as a nice-to-have product for which Princeton is not ready. We also questioned the value of this functionality versus the current costs anticipated to implement it. Because there are new developments in the portal world every week, we are quick to caution that this area is a moving target, and we can only take a snapshot of our recommendations at this moment.

We believe that several of the critical success factors for a successful enterprise portal are missing at Princeton:

• We do not have a groundswell of support for a common portal.
• We do not have a strong customer advocate who will champion this effort and manage the political implications of consolidating all of our information into one place.
• We are not sure that the resource requirements of dollars and people, both to build the portal and to sustain it, exist.
• We do not feel we have sufficient content to deploy through a portal that would justify its effort.

We believe Princeton’s long term needs would be better served by putting its short term efforts into developing content, including self-service functionality. We should continue to work in our domain portals such as Blackboard, especially in the area of testing their extensibility. We can, however, better position ourselves from a technical point of view if we allow development of these efforts within the constraints of architectural guidelines, which are articulated later in this document. This will facilitate adding an integration layer to these separate worlds in the future.

Our long term recommendation is for the group to reconvene every six months and reevaluate the effort, costs and benefits of an enterprise portal. Part of this evaluation is an assessment of the political environment and the customer advocacy for a project of this sort.

Current Portal Environment at Princeton University

The word portal is used to mean many different things, and some “portals” at Princeton are not true portals at all. In order to ensure that we spoke in consistent terms, the group settled on a simple working definition of a portal:

A portal provides personalized access to commonly used data and applications via the web.

Using this definition, we found there are six areas using portal-like functionality at Princeton:

1. Alumni: This area uses a commercial portal from PCI using a proprietary framework. This is Tigernet.Princeton.edu. The Alumni Council is currently rethinking its strategy, and possibly moving toward a website instead, since their feeling is that alumni don’t want personalization or other portal functionality. The only integration that is taking place with the PCI portal is with headlines which are pulled from the Princeton home page. BSR offers an Advance Web Community product. It is unclear how or whether that will be used in the future. As of January, 2005, the Development Office is using Advance Web Community in conjunction with its BSR package, but is experiencing version incompatibility issues that are keeping us from moving to the next version.
2. Treasurer’s Office: The existing system was at one time called a portal, but is now called a gateway. It is a nice website that has no underlying portal framework, no personalization or authentication, and uses only links for integration.
3. Student Portals: There are currently no working student portals, although there is a plan for the USG (Undergraduate Student Government) to maintain a student-centric “My Princeton”. It is not clear what portal product they intend to use. As of January, 2005, the USG has a student portal up and running. http://point.princeton.edu Although it uses LDAP authentication, we would not consider it to be a robust, production worthy environment. It runs on a student’s machine in his dorm. The USG is considering moving it to a shared OIT server, but has not secured the $50.00/month funding it would require. Students are using this portal and it has been covered in the local press, but we are unsure of its future sustainability. We also have no way of knowing what the application is doing with the LDAP id/pw pairs, in terms of just authenticating, storing them, etc.
4. Blackboard: Blackboard Portal is a robust true portal framework that integrates well with their Learning Management System. We are currently testing its extensibility, using its Java API and building blocks strategy. This will tell us how useful it will be for integration with other systems. The underlying technology is proprietary to Blackboard, but the provided APIs expose the functionality in a way that allows other systems to integrate. Some common processes are externalized, most notably authentication. The portal handles personalization by maintaining a profile on each user, and storing it in a proprietary way. There is a very robust administrator interface for managing the environment and configuration. As a result of the OKI/Sakai initiatives, we should see Blackboard portal move toward adoption of JSR168 and WSRP standards.
5. Demand: This is the only instantiation of uPortal at Princeton. It is used for a departmental manager constituency of approximately 350 members. It is currently being used for only one role and minimal customization, and therefore is not taking advantage of its portal features. It does allow for external LDAP authentication, and supports several different types of channels. It stores personalization/profile information in a database; in the case of Princeton, Oracle.

   The retirement of Demand has been announced for June 30, 2005.

   It should be noted that, being open source software, uPortal will be the underlying portal framework for Sakai, and funding for JSR168 adoption in uPortal is part of the project.

6. PeopleSoft: Even though the PeopleSoft portal is not currently installed at Princeton, it is important for us to consider this portal because we are such large PeopleSoft customers. This is a separately priced product and is expected to continue to be so for the foreseeable future. It is proprietary in nature, both internally and in the sense that it does not expose itself well to integration with other systems. Its long term strategy is to adopt JSR168 only to allow incoming channels, not to allow its content to be deployed elsewhere. Given the fact that the integration strategies, offered, such as Component Broker, are point-to-point solutions that have had varying degrees of success on campuses, it remains a very closed environment. It is important to note that business rules are integrated into the PeopleSoft portal itself, and some PeopleSoft functionality will never be able to deploy easily in other portals. For this reason alone, we should continue to monitor the PeopleSoft portal.

   As of January, 2005, Oracle has taken over PeopleSoft, and we are unsure of the future of any of the PeopleSoft products, including the PeopleSoft portal. It is unlikely we would pursue this product given these circumstances.

7. Cognos/ReportNet Portal: We have purchased and installed this product to be our new, enterprise data warehouse. It uses LDAP authentication and holds in a portal framework profiling information that includes authorization to access certain reports. As a result of this migration from our current Data Mall to ReportNet, we will no longer have Oracle Portal in house.

Findings and Recommendations

1. Princeton should not pursue one enterprise portal at this time.
2. Princeton should allow certain domain portals to meet the needs of specific constituencies. If domain portals are to be developed, they should, however, conform to standards and architectures to be articulated by OIT. Anything that’s developed now should be done with the expectation that it will eventually become a piece in a campus enterprise portal.
3. We should put our efforts into developing content, especially on the administrative side, to avoid deploying an empty portal.
4. We believe that if we architect multiple portals, then authentication should happen in one place in the enterprise portal framework, and the underlying portals should be used purely to provide access to applications or data.
5. We should limit the products/vendors. This would include Blackboard portal, uPortal, and potentially PeopleSoft portal and Oracle Portal, since these vendors have a significant presence on campus already. We should not introduce additional portal products.
   • Blackboard portal should be enhanced to meet the portal needs of students and faculty. A cross-section of OIT members should investigate its extensibility and potential as an enterprise portal. It remains to be seen how well it integrates with other systems. Blackboard is where we currently experience the highest expression of customer need.
   • uPortal/Demand has lost its customer support at Princeton, but is gaining support elsewhere. We will retire the Princeton implementation on June 30, 2005. Due to recent developments, as with Sakai, we will watch the progress of uPortal closely. Sometime in the future, especially if it adopts the new JSR168 and WSRP standards much more quickly than other portals, it may be a viable enterprise portal for Princeton.
   • PeopleSoft portal is worth watching because it is tightly integrated with the PeopleSoft applications that we already have in house. It is possible that it will be a required element in future PeopleSoft application deployment. Because of its closed, proprietary architecture, however, we will not consider it as an enterprise portal, but it could potentially be a vertical portal that hangs under a different enterprise framework. Because of Oracle’s takeover of PeopleSoft, the PS Portal has lost its viability..
6. We should leverage our OIT resources to concentrate on learning and supporting one portal framework. For now, we believe that developing Blackboard portal in the academic space is the best use of our resources.
7. This group should meet every six months to reassess the portal situation, both inside and outside of Princeton.
8. Any development in content, portal functionality, or common services should conform to technical guidelines recommended by the team.

Technical Guidelines

1. Portlets should adhere to JSR168 and WSRP where possible.
2. Portal frameworks should support JSR168 and WSRP if possible.
3. Applications/content should be independent of any portal framework. Abstraction logic should be used to insulate the two.
4. Dependencies on browser functionality (frames, javascript, etc.) should be avoided, especially for outward facing applications.
5. At a minimum, produce well formed HTML and/or XHTML. Consider use of XML and XSLT to facilitate alternate clients. Mobile devices (handhelds, PDAs, etc.) and ADA compliance are current trends that should be considered.
6. A content management system should be employed to distribute ownership and responsibility for content.
7. Authentication via LDAP, or potentially WebISO or CAS.
8. Minimize number of signons.
9. Authorization should be defined at the application level, independent of any portal.
10. Constituency attributes should be held in a central directory, as opposed to in the portal.
11. If we find ourselves using nested portals, the “über” portal should have responsibility for all common services. Any underlying portal should only be used for access to the applications/functionality.

Future Considerations for Deployment of an Enterprise Portal

We have identified some critical success criteria to be used when it is determined we want to revisit building an enterprise portal. We have also identified a list of stakeholders and potential focus groups that could be used for outreach to determine value and gather requirements.

Critical Success Factors

• Executive Sponsorship;
• Strong Governance and broad participation;
• Shared vision;
• Clear ties to business objectives and goals;
• A good content strategy to avoid deploying an empty portal;
• Good choice of portal tools;
• Resourcing for implementation as well as ongoing support.

Identified list of stakeholders

• Treasurer
• Human Resources
• Dean of the Faculty
• Development
• Library
• Dean of Student Life (Athletics, Frist, Health and Safety)
• OIT
• Graduate School / Grad School Admissions
• Engineering
• Provost
• Senior VP of Administration
• Registrar
• Woodrow Wilson School
• Facilities (Public Safety, Housing, Dining)
• AMG (Academic Mgrs Group)
• Faculty (Humanities, Science, Social Science)
• USG (Undergraduate Student Govt)
• Public Affairs and Communications
• Alumni Council
• Departmental Managers
• Prospective Students
• Prospective Parents

Existing Groups that could act as Focus Groups

• CAT: Committee on Academic Technology;
• RCAG: Research Computing Advisory Group;
• Faculty Committee on Computing and the Library.

Technical Considerations

As portal technology matures and standards emerge the architectural recommendations regarding portals will become clearer. There are two critical standards that should directly impact any portal decision. JSR168, commonly called a “portlet” standard, will enable a channel that is developed anywhere to be run in any framework that supports the standard. This will enable Princeton to take advantage of content from many sources. WSRP is a standard that will enable remote hosting of a channel or portlet. The channel could run at another university, but appear in a Princeton portal. Especially in higher education, with its atmosphere of sharing and collaboration, this will be important.

IT Architecture Team
Portal Strategy Sub-team

Charter

Introduction / Background

Several portals have emerged on campus, (Blackboard Student Portal, Demand/uPortal and the Data Mall Oracle Portal,) and others are envisioned: HR wants a portal to manage their self-service applications, the Treasurer’s Office has an emerging “portal”, Development’s BSR’s Web Community is in process. In addition, there are current and pending applications (e.g., WebEvent campus events calendar, and web content management) which could either leverage or be leveraged by a “portal.”

Goals

1. To investigate and evaluate the opportunities, needs, and risks of an enterprise portal at Princeton.
   • Investigate university and other portals for “best practices” concepts.
   • Focus groups with users on campus as to what might constitute a “killer portal” for Princeton.
   • In depth interviews discussions with “portal visionaries” within and outside Princeton to create both a vision and business case for a Princeton Portal.

2. To identify and describe the existing/nascent portals and related technologies on campus:
   • Who are the owners, data providers, and users of the portal?
   • How might or should the set of users grow?
   • What additional content, not currently in the portal, is planned for or desired?
   • What interfaces/APIs, if any exist, for adding or providing access to information in the portal?
   • To what extent can centralized services (authentication, authorization, role determination, profile information, etc.) be used by the portal?

3. To investigate and evaluate the opportunities, needs, and risks of a single Princeton Portal.
4. To ascertain the role, if any, of existing or future “vertical portals” at Princeton.
5. To evaluate resourcing requirements involved in supporting integrated vertical portals and integrated data into a centralized portal.
6. To make recommendations regarding strategy, architecture, software, and resourcing regarding a central and vertical portals at Princeton.