Academic Services Portal Project

Defining options for portal implementation

Version 1.0

A document which presents options for institutional portal implementation at the University of Leeds. The options are briefly described and costings presented for each along with the advantages and disadvantages of progressing with each scenario. A comparison of the scenarios is summarised on pages 9 &10 of this document.

The options presented here are based on the outcome of research undertaken by the Academic Services Portal Project Manager (ASPPM) full details of which can be found in a series of reports at

Bo Middleton

Academic Services Portal Project Manager

Version / Date / Audience / Notes
Ver1.0 / 05/08/04 / TSS, CC, AE and MB

Contents

1.Selection of the implementation options

2.Options for portal implementation

2.1.Revamp Campusweb

2.2.Develop using uPortal

2.3.Buy/implement Luminis Basic

3.Comparison of scenarios

4.Outstanding Issues

Appendix A Functional requirements mapped against scenarios

Appendix B Content requirements mapped against scenarios

Appendix C Content requirements mapped against level of customisation

Appendix D uPortal Case Studies


  1. Selection of the implementation options

The purpose of this document is to present outline costings for some institutional portal implementation options.

The implementation options have been chosen based on the outcomes of previous work undertaken by the ASPPM and on conclusions drawn during discussions about the Information Architecture Strategy.

Initially the following implementation options were mapped against the requirements specified by “Requirements Specification Report”:

  1. Revamping Campusweb
  2. uPortal – out of the box functionality
  3. uPortal– plus time spent on development and/or adopting/adapting open source channels
  4. SCT Luminis.

Details of this mapping can be found in appendices A and B.

uPortal, from the Java Architectures Special Interest Group (JA-SIG), is an open-source enterprise portal collaboratively developed by higher-education, for higher-education. uPortal is one of the most widely used portal technologies in higher education with over 100 institutions worldwide having implemented uPortal on campus. Utilising Java, XML, JSP, and J2EE technologies, the uPortal framework enables standards-based integration with authentication and security applications, single sign-on, secure access and end-user customisation. uPortal has very basic functionality when initially installed, though there is an open-source community which shares channels (i.e. code developed by other HEIs which can be reused/adapted to suit).

SCT Luminis was chosen as the ‘purchase’ scenario since it is based on uPortal and thus offers the possibility of uPortal development being undertaken and integrated into the SCT Luminis framework. Also, Luminis has ‘out of the box’ links to Banner (used in creating course groups and online communities). This choice is not intended to preclude purchase/implementation of other portal products, merely to gauge the cost of implementation using a ‘ready made’ option.

In addition, discussions at an ISS Information Architecture away day indicated that the level of customisation required to deliver content was seen to be key to making a decision about the type of portal infrastructure required. Level of customisation mapped against content requirements is given in Appendix C.

Finally, mapping functional requirements against the 4 scenarios clearly indicated a need to understand the development time required to implement a portal using uPortal. Case studies which outline the experiences of two other UK universities implementing uPortal are given in appendix D.

Each of these appendices thus contributed to the decision to actually outline and cost 3 scenarios:

  1. Revamping Campusweb
  2. Developing a portal using uPortal – to include time spent on development and/or adopting/adapting open source channels
  3. Purchasing/implementing SCT Luminis portal.

  1. Options for portal implementation
  2. Revamp Campusweb

Scenario description:

  • Card sorting with users in order to landscape tasks and content taxonomy.
  • Usability testing to create an easily navigable site with role-based pages and clear links to web enabled service.
  • Port Campusweb content into CMS.

Cost:

  • Employ web programmer on 1 year contract.
  • Employ short-term contract clerical support for porting current content into CMS.
  • Cost of usability testing.

Year 1
Usability testing / 4000
Staffing / 33661
Software / 0
Hardware / 0
Training / 0
Total / £37661

Advantages:

  • Achieves key functionality:
  • Ease of finding information on the web
  • Customisation (i.e. tailoring content to roles)
  • Reduced sign on for on campus users.
  • Relatively low cost for 1 year and no on-going costs.

Disadvantages:

  • Doesn’t achieve key functionality:
  • Off-campus access to IP protected content
  • Reduced sign on for off campus users
  • Personalisation (i.e. user ability to personalise interface)
  • Customisation is for broad roles only and no ‘push’ of information to finer roles is possible.
  • Collaboration tools.
  • Doesn’t addressthe political problems currently faced by Campusweb – no web strategy, no single point for Campusweb updates, no expert content creators.
  • Doesn’t take us forward (only improves current state).
  • No exit strategy for the year.

Assumes:

  • CMS available.
  • Improved search engine available through CMS or other means.
  • Library Management System and Bodington move to authentication against AD and Kerberos is used to provide SSO (also applies to any other system which may want to offer SSO for = e.g. Banner for students).

2.2.Develop using uPortal

Scenario description:

As for Scenario 1 plus:

  • Install and configure uPortal.
  • Link uPortal to AD for authentication.
  • Where possible, use uPortal clearing house to adopt others’ (free) channels.

Cost:

  • Employ 3 JAVA programmers for first year and 2 in subsequent years.
  • Employ short-term contract clerical support for porting current content into CMS.
  • Cost of usability testing.
  • Consultancy costs (assessment, capacity planning and possible custom channel development from third party uPortal specialists).
  • uPortal training.
  • Hardware costs.

Year 1 / Year 2 / Year 3 / Year 4 / Year 5
Usability testing / 4000 / 0 / 0 / 0 / 0
Staffing / 106551 / 81684 / 81684 / 81684 / 81684
Software / 0 / 0 / 0 / 0 / 0
Hardware / 30000 / 0 / 0 / 0 / 30000
Training / 9000 / 0 / 0 / 0 / 0
Consultancy / 35000 / 0 / 0 / 0 / 0
Total / 184551 / 81684 / 81684 / 81684 / 111684
Five year total / £541287

Advantages:

  • Achieves key functionality:
  • Ease of finding information on the web
  • Customisation (i.e. tailoring content to roles)
  • Reduced sign on for on campus users
  • Personalisation (i.e. user ability to personalise interface)
  • Unlimited number of ‘roles’ and ‘push’ of information to finer roles is possible.
  • Potential to develop further or adopt a platform that can use uPortal channels (i.e. Luminis or Academus).
  • Provides the ability to develop/offer roles (wouldn’t be possible to do this in first year) and thus offer more customised content.
  • Potential to offer a staff/alumni/potential student portal.

Disadvantages:

  • Doesn’t achieve key functionality:
  • Off-campus access to IP protected content
  • Reduced sign on for off campus users
  • Collaboration tools.
  • Doesn’t address the political problems currently faced by Campusweb – no web strategy, no single point for Campusweb updates, no expert content creators.
  • No roles initially (time to ‘integrate’ Banner and/or read grouping information in AD).
  • On-going costs of maintaining JAVA programmers to support, maintain, administer and continue development.

Assumes:

  • CMS available.
  • Improved search engine available through CMS or other means.
  • Library Management System and Bodington move to authentication against AD and Kerberos is used to provide SSO (also applies to any other system which may want to offer SSO for = e.g. Banner for students).

Issues:

If implementation by developing using uPortal is to be considered then the following issues should be taken into account:

  • uPortal utilises Java, XML, JSP, and J2EE technologies. The experience of other universities indicates that recruiting staff with these skills and knowledge of uPortal is very difficult. A considerable amount of time is subsequently needed in order for staff to feel familiar with developing/adapting channels for the uPortal framework.
  • Whilst it is possible for uPortal to authenticate users against AD, consideration needs to be given to further directory services – since information about a user is the key to providing portal ‘roles’. It would be a relatively simple process to assign users to ‘staff’ and ‘student’ roles since the authentication directory service would contain this level of information. In order to further customise portal screens, it will be necessary to draw on information contained in Banner for students and SAP HR for staff. This type of work would greatly increase initial development time.
  • Purchasing a portal solution usually offers a range of options for simplifying sign on. There are a number of options for reducing sign on which need to considered in conjunction with AD/Kerberos in order to offer off campus access to applications and web content

2.3.Buy/implement Luminis Basic

Scenario description:

As for Scenario 1 plus:

  • Install and configure Luminis.
  • Create department based student roles (Banner integration out of box).

Cost:

  • Employ I support/administrator/programmer.
  • Employ short-term contract clerical support for porting current content into CMS.
  • Cost of usability testing.
  • Software purchase and consultancy costs for training/implementation.
  • Hardware costs.
  • Ongoing support costs.

Year 1 / Year 2 / Year 3 / Year 4 / Year 5
Usability testing / 4000 / 0 / 0 / 0 / 0
Staffing / 32048 / 32048 / 32048 / 32048 / 32048
Software / 132000 / 26000 / 26000 / 26000 / 26000
Hardware / 30000 / 0 / 0 / 0 / 30000
Training / 0 / 0 / 0 / 0 / 0
Consultancy (includes training) / 66000 / 0 / 0 / 0 / 0
Total / 264048 / 58048 / 58048 / 58048 / 88048
Five year total / £526240

Advantages:

  • Achieves key functionality:
  • Ease of finding information on the web
  • Customisation (i.e. tailoring content to roles)
  • Reduced sign on for on campus users
  • Personalisation (i.e. user ability to personalise interface)
  • Unlimited number of ‘roles’ and ‘push’ of information to finer roles is possible (out of the box integration with Banner)
  • Off-campus access to IP protected content
  • Reduced sign on for off campus users
  • Collaboration tools.
  • Potential to develop uPortal channels and integrate into the Luminis platform.
  • Potential to create service based channels instead of links to web enabled products.
  • Provides a true SSO solution.
  • Potential to integrate in other applications.
  • Potential to offer a staff/alumni/potential student portal.

Disadvantages:

  • On-going costs for Luminis support (internal and software support)
  • Doesn’t address the political problems currently faced by Campusweb – no web strategy, no single point for Campusweb updates, no expert content creators.
  • On-going costs of Luminis product plus member of staff to administer/support the portal infrastructure long-term.

Assumes:

  • CMS available.
  • Improved search engine available through CMS or other means.

Issues:

If implementation by purchasing the Luminis solution is to be considered then the following issues should be taken into account:

  • The various parts of Documentum’s Enterprise Content Management System can be purchased separately. The content management system (CMS) bundled with Luminis is based on Documentum’s web CMS. Buying this CMS is cheaper when bundled with Luminis than if bought separately.
  • The version of web CMS bundled with Luminis is version 3 of Documentum’s web CMS. Purchasing the CMS separately would mean purchase of version 2 of Documentum’s CMS. SCT have done a substantial amount of working in making the web CMS more user friendly (There is anecdotal evidence to show that version 2 is difficult to implement).
  • Since SCT Luminis is the only portal product with out of the box links to Banner it may be possible to circumvent the tender process by purchasing based on single supplier status (this has been achieved by both University of Birmingham and University of Nottingham).
  • Maintenance agreement for Banner could be renegotiated if SCT Luminis is adopted (as for Birmingham).

1

  1. Comparison of scenarios

Scenario 1 / Scenario 2 / Scenario 3
Costs / 1 web programmer (Grade 2)
½ clerical/admin (Grade 3)
Usability testing / 2/3 JAVA programmers (Grade 2/3)
½ clerical/admin
Staff training
Usability testing
OS software
Hardware
Consultancy / 1 support/administrator/programmer (Grade 2)
½ clerical/admin
Staff training
Usability testing
OS software
Hardware
Consultancy
Total costs first year / £37661 / £184551 / £264048
Total costs subsequent years / 0 / £81684 / £58048
Total cost over 5 years / £541287 / £526240
Key functionality which scenario achieves /
  • Ease of finding information on the web
  • Customisation
  • Reduced sign on for on campus users.
/
  • Ease of finding information on the web
  • Customisation
  • Reduced sign on for on campus users
  • Personalisation (i.e. user ability to personalise interface)
  • Unlimited number of ‘roles’ and ‘push’ of information to finer roles is possible.
/
  • Ease of finding information on the web
  • Customisation Reduced sign on for on campus users
  • Personalisation (i.e. user ability to personalise interface)
  • Unlimited number of ‘roles’ and ‘push’ of information to finer roles is possible (out of the box integration with Banner)
  • Off-campus access to IP protected content
  • Reduced sign on for off campus users
  • Collaboration tools.

Key functionality which scenario doesn’t achieve /
  • Off-campus access to IP protected content
  • Reduced sign on for off campus users
  • Personalisation (i.e. user ability to personalise interface)
  • Customisation is for broad roles only and no ‘push’ of information to finer roles is possible
  • Collaboration tools.
/
  • Off-campus access to IP protected content
  • Reduced sign on for off campus users
  • Collaboration tools.

Advantages /
  • Relatively low cost for 1 year and no on-going costs.
/
  • Potential to develop further or adopt a platform that can use uPortal channels (i.e. Luminis or Academus).
  • Provides the ability to develop/offer roles and thus offer more customised content.
  • Potential to offer a staff/alumni/potential student portal.
/
  • Potential to develop uPortal channels and integrate into the Luminis platform.
  • Potential to create service based channels instead of links to web enabled products.
  • Provides a true SSO solution.
  • Potential to integrate in other applications.
  • Potential to offer a staff/alumni/potential student portal.

Disadvantages /
  • Doesn’t address the political problems currently faced by Campusweb – no web strategy, no single point for Campusweb updates, no expert content creators.
  • Doesn’t take us forward (only improves current state).
  • No exit strategy for the year.
/
  • Doesn’t address the political problems currently faced by Campusweb – no web strategy, no single point for Campusweb updates, no expert content creators.
  • No roles initially (time to ‘integrate’ Banner and/or read grouping information in AD).
  • On-going costs of maintaining JAVA programmers to support, maintain, administer and continue development.
/
  • On-going costs for Luminis support
  • Doesn’t address the political problems currently faced by Campusweb – no web strategy, no single point for Campusweb updates, no expert content creators.
  • On-going costs of Luminis product plus member of staff to administer/support the portal infrastructure long-term.

Issues /
  • Simplifying sign on for off campus access to applications and web content.
/
  • Training. Time to familiarise (i.e. initially slow development effort).
  • Directory service for role information. Increased initial development time.
  • Simplifying sign on for off campus access to applications and web content.
/
  • Content management bundled with Luminis is cheaper than buying separately.
  • Also need to bear in mind that SCT have done a lot of work in making web CMS part of Documentum more user friendly.
  • Documentum – can be unbundled and different bits bought separately.
  • Single supplier status.
  • Maintenance agreement for Banner could be renegotiated if SCT Luminis is adopted (as for Birmingham).

1

  1. Outstanding Issues

A number of issues have been raised throughout the research undertaken by the ASPPM and these have been highlighted in the various reports which have been produced. The following summarises those issues which may impact on the choice of implementation option.

4.1.Initial level of integration

Though level of customisation has been considered, the level of integration which is closely linked to customisation needs also to be considered. A recommendation to adopt the simplest level of integration was made as part of the Requirements Specification Report. This recommendation was based on the need to implement a portal for the 2005/06 academic year. To clarify, varying levels of integration can be simplified as:

  • The portal provides a web link to a web-enabled application. The application may then open in another browser window. The user must then use the application’s own user interface and will need to login to access personalised information.
  • The portal provides an ‘authenticated’ web link to a web-service. Similar to the previous level, but the portal (or other) infrastructure provides a sign on methodology – matching the user to their account on the remote application. Thus a user would not need to logon to applications after having logged onto the portal. Ideally this would also be offered to off-campus users.
  • Instead of offering a web-link to a web-enabled application, the portal offers a channel which gives access to the data/content drawn from an application. In such cases, a portal infrastructure’s integration toolset can extract information from a database (or even from several databases) and present the information in the portal as a ‘service’. It may also be possible to offer a transactional ‘service’, i.e. a channel which allows the user to update information or carry out some action – with data then being fed back to the source application.

Project work on user requirements did not identify a clear choice of ‘level of integration’, this decision is however, more likely to be based on a strategic choice combined with the portal infrastructure’s capability. There are a number of benefits to be gained from a university espousing the portal as a means of web-enabling services including cost savings and adoption of a single, consistent user interface. It is essential that the possibility of using the portal to provide web services in the future is considered in order to ensure that the portal infrastructure adopted offers this potential.

4.2.Portal potential

Directly related to consideration of level of integration is the wider issue of understanding future needs in order to ensure that the portal infrastructure adopted can fulfil those needs. The portal platform’s infrastructure must be flexible and technologically sound in order that subsequent development will be possible (and will be relatively cheap since the infrastructure for development and delivery will already be in place). On this basis, a portal may be considered (in terms of cost) more of an infrastructure investment than it is an application.

The focus of the portal project so far has primarily been on scoping requirements for a student portal although staff needs have also been considered. The functional requirements for a staff portal will not vary greatly from those already identified though obviously content requirements will vary. A key lesson learned from other HEIs who have already implemented an institutional portal is that student and staff portals may look different but that they need to operate using the same portal infrastructure in order to improve communication and collaboration between staff and students and in order to improve workflow. Having one portal infrastructure for both staff and students also offers the possibility of having a lifecycle portal – that is one that will change roles/views when a student moves from being and undergraduate to a postgraduate or alumni. At this stage, it is not essential to determine whether the student portal will be expanded to offer a staff portal but specification of hardware and software may vary if staff/alumni/applicants will later be included.