![[Figure 1: Typical my.monash homepage]](homepage.gif)
Nathan Bailey [HREF1], Manager, Development+Integration, Flexible Learning and Teaching Program, Information Technology Services [HREF2] , PO Box 3A, Monash University [HREF3], Victoria, 3800. Nathan.Bailey@its.monash.edu
Dr Andrew Treloar [HREF4], Manager Web and Internet, Infrastructure Services, Information Technology Services [HREF2] , PO Box 28C, Monash University [HREF3], Victoria, 3800. Andrew.Treloar@its.monash.edu (NOTE: Originally refereed as authored by senior author only, in order to preserve the integrity of the refereeing process)
Enterprise portals are rapidly becoming an essential part of the organisation, and the rationale is simple - an organisation's most valuable resource is its people and their knowledge and experience. An enterprise portal is a means to collating and disseminating this information in a automated, specific and relevant way.
There are two key elements that make up a portal -- that it is customisable, and that it is constantly and automatically updated with new information. An enterprise portal adds the element of personalisation, wherein information from other corporate systems is used to automatically tailor the portal's settings to individual users.
This paper describes how to build a portal from scratch, using industry-standard, open source technologies. Whilst the view is somewhat technical, it is mostly a strategic blueprint for action, rather than specific in-depth instructions. The example portal used is my.monash [HREF20].
The paper concludes by considering future developments for the my.monash portal in particular and portals in general.
This paper discusses portals in terms of the infrastructure needed to support all the things that portals do. We begin by providing a high level description of what a portal is, and how an organisation like a university might make use of it. Then we discuss the infrastructure needed to support such a portal, using the my.monash portal developed at Monash University as a specific example. Finally, we conclude by looking at likely directions for portals in general and my.monash in particular.
A portal can be defined as "A Web site or service that offers a broad array of resources and services, such as e-mail, forums, search engines, and on-line shopping malls. The first Web portals were online services, such as AOL, that provided access to the Web, but by now most of the traditional search engines have transformed themselves into Web portals to attract and keep a larger audience." [HREF5]
Stated like this, a portal sounds a lot like a gateway, providing efficient access to a range of things. In practice, most current portals have tried to improve on the gateway model, by providing personalisation and customisation features. This means that everybody's portal is (potentially) different.
Portals are increasingly being positioned as the solution to an organisation's Knowledge Management (KM) and Knowledge Access (KA) needs. That is, as a knowledge worker, all the pieces of information you need to access, and all the knowledge applications you need to use, will be made available to you through a Web portal. This is a very bold vision, and it is unclear if it will ever be completely deliverable.
There are now a wide and increasing number of 'portal toolkits' which intend to simplify the process of building portals, using a variety of different toolsets from expensive, document-focused repositories like Lotus Domino, through cheap out-of-the-box solutions like Zope, through to Java-based solutions providing rich functionality from a sophisticated set of servlets which can be added to. In fact, every time one looks, another software manufacturer is trying to convince you that they have been doing portals for years and their solution is superior to all the others.
The focus of this paper is not on any of these toolkits. Rather, we want to discuss the elements which are required to build a portal. Following Ockham's Razor [HREF6], the architecture employed is the simplest one, but the authors trust that the methodology will equally apply to other, more complex solutions. To use a somewhat forced analogy, this paper explains how to source a range of components to build your own bicycle. You can buy a pre-assembled bicycle, but it is still probably a good idea to understand what the components are and how they interact.
Monash University is an organisation with over 50,000 people spread over nine campuses and centres with a presence in growing number of countries. Recognising this diverse environment, strategic plans called for a portal-type system to support the corporate, administrative and learning and teaching needs of the University as it increasingly became a global organisation.
At the time (late 1998), the portal market was quite immature. Whilst sophisticated commercial portals existed (Yahoo, Netscape, etc), there were no standards and certainly few systems to provide a portal environment. After surveying existing implementations, Monash initiated developments based around Apache [HREF7], HTML::Mason [HREF8] (integrating Perl into HTML in an ASP-like way) and Oracle [HREF9].
Our service has now been serving staff and students for nearly two years, and offers a continually expanding range of services and applications in an increasingly rich, personalised environment. This incremental, rapid prototyping model lends itself well to portals (and KM systems in general) since the needs of the organisation are constantly changing, and the niche solutions grow from infancy to maturity to death in increasingly rapid cycles.
To do their jobs, members of the community need only to learn how to use the enterprise portal, my.monash. Services may be added, or, if proved insufficient, removed, and the users can continue to use something they understand and are familiar with, without having to relearn complex new systems. This is an important part of ensuring that the portal provides a service to the community, without becoming a burden in terms of facilitating the enterprise's needs for knowledge management and global access.
A typical user's initial screen on my.monash looks like Figure 1.
In order to build an enterprise portal, one needs four components:
There are four main ways of authenticating to a web site using HTTP. The earliest used and simplest is HTTP authentication. Unfortunately, this has a major shortcoming -- the only way to log out is to quit the browser entirely. In a system so personal and powerful as a portal, security is critical, so it is essential that there is some means both to explicitly log out and to time-out the session.
The remaining three ways are cookies, session keys and personal certificates.
Personal certificates rely on the existence of a Public Key Infrastructure to distribute the certificates and to bind each certificate to an individual. PKI is not a widely supported technology yet for a variety of reasons. Providing personal certificates to individuals has problems associated with the difficulties of scaling up the binding process and distributing this geographically. As a result most organisations are not ready to deploy them across a large range of people.
Session keys involve creating sessions for each transactional interaction between web site and user. These typically involve complicated URLs and/or passing hidden keys through every page (via hidden form fields), which can be a little messy.
Cookies are a way of turning HTTP (which is a stateless protocol) into a stateful protocol. Technically, a cookie is a line (or series of lines) in a special text file stored on the user's hard disk. Cookie-based authentication allows the provider to choose whether closing the browser terminates the session or not, so that security can be permanent (eg. on a staff-member's desktop) or transient (eg. on a lab PC). We have decided to use cookies for my.monash. The cookie contains session information and is encrypted for added security.
It is imperative that the password exchange take place over a secure connection, since most portal users will not be on the private corporate network (not that this is secure either!), but on the public Internet. Whether to use HTTPS for the entire session or not is a question for the organisation, in terms of the desired security for the information being passed through the connection. At the moment, my.monash has chosen to enforce HTTPS for the initial authentication challenge and then to revert to HTTP for the rest of the session, although users can choose to continue with HTTPS if they so desire.
In terms of validating the credentials, there should also be encryption from the web server to the password validation system (this communication should only be over a trusted internal network). By far the most common system in emergent use for usernames, passwords and ``white pages'' information is an LDAP-based directory service.
It is clear that all major organisations are moving toward directory services, whether they are using Novell's NDS, Microsoft's ActiveDirectory or more open implementations of the LDAP standard. Directory servers are highly optimised for reading, to ensure that applications such as mail, news or web-access can quickly check access-control and other user profile information without introducing significant lookup latencies. Monash University (and my.monash) has chosen to use the iPlanet LDAP Directory Server [HREF10].
Setting up a directory service can be a complex process. To be useful, a directory service must include account information, role information and departmental affiliations, so that it can handle the breadth of authentication, identification and access control. Questions that directory servers answer along these lines include 'Is that the right password for Jane?', 'Is Jim a manager?' and 'Is Lim a member of this department?' At Monash, the main sources of this information are SAP-HR (our Human Resources system) for staff information and Callista (our student information system) for student data.
The true power of a directory server really becomes apparent once all corporate systems use it, so that people can use a single username/password combination to access all of their online services (although they may have to re-authenticate for each service).
Where extra information is required, it can be retrieved from a single, authoritative source (thus avoiding stale or conflicting information across multiple sources). This is a first and crucial step toward single-sign-on (authenticating once in order to access all services). The closer an organisation works towards this, the more power a portal can offer, because it can integrate content from systems which share the same authentication scheme.
The database serves as a more sophisticated repository of information about the portal users, their preferences and the information available to them. Whilst much of this information could be stored in a directory, it would serve to bloat what should be a global, concise service with information that is specific to only one application (the portal), where the directory's purpose is to serve as a common repository of information for many applications.
Monash decided to use Oracle for my.monash as it is our corporate database standard, though mySQL [HREF11] or PostgreSQL [HREF12] would serve equally well for those whose budget does not run to Oracle.
Our database stores:
It is imperative that a portal be a source of timely, relevant information. This topic is so broad that one of the authors (Bailey) has co-written another paper for this conference entitled "Personalisation Issues Surrounding the Enterprise Learning Portal."
To summarise the important points:
The portal should not attempt to reproduce content in its entirety, but instead should serve as a conduit of information, summarising links and otherwise précising larger pieces of content. Its intention is to provide full access to relevant information at the fingertips, but not to overwhelm with huge chunks of content.
Correctly matching relevant information to the people who need that information is the key to making a portal useful, both for the individual (who will continue to use the portal as a rich source of information) and the organisation (whose power to collate and disseminate information is in direct proportion to the levels of usage of the system).
So what sort of functionality can such an architecture provide? We discuss functionality categories with reference to what my.monash provides, broadly categorised into customisation, integration and dissemination.
The above architecture does not imply an individual portal experience. It could easily be used to generate a single monolithic portal, or a series of portals for different employee/user community roles.
In our view, a critical key to success for a portal is allowing people to tailor the available information and its style of presentation. A simple-to-use and yet powerful customisation system is required. Monash has employed an XML-based summary of user's channels, which is rendered in HTML for display, and can be enhanced, cut down or removed by users as they see fit.
At Monash, we do not provide one or ten my.monash portals. We have (potentially) 65,000 different my.monashes, one for each staff and student based on their customisation choices.
In the my.monash portal, there are four areas that users can customise: content, layout, presentation and profile information.
Content customisation is fairly obvious. Users can choose what kinds of content they wish to add (or remove) from their portal, and where they would like to put it. There are two ways to find the relevant piece of content in our 'resource catalogue' of available resources, which mirror the two main search strategies on the Web.
Firstly, users can type in key words in a search-engine style interface, which provides ranked results based on their key words, with a link to ``Add this component.'' Secondly, users can progress through a Yahoo!-style hierarchy of categories in order to find relevant resources grouped by topic.
In addition, users can add their own URLs, or integrate syndicated information from other websites (using the RSS/RDF standards [ HREF13 ]), discussion groups (based on NNTP) and any public mailing list archives based on the MHonArc [ HREF14 ] or MailMan [ HREF15 ] archiving formats.
A content customisation screen is shown in Figure 2.
![[Figure 2: Customising my.monash home channel]](customise.gif)
Resources can be placed anywhere on the page. Changing the order of resources is the domain of layout customisation.
Changing layout allows people to shuffle the resources around on their page so that more relevant resources can be placed at the top and less frequently viewed ones can be placed at the bottom. This is simply a process of changing the order in a list of resources.
Resources can also be grouped into channels. A channel aggregates a wide range of related resources together: internal links, external links, news or mail feeds. Users can define their own channels or choose to use shared channels. Such shared channels might be of relevance to a department or Faculty within the university or a project team. Access to shared channels might be open to all or restricted to members with particular profile information.
A layout customisation screen is shown in Figure 3.
![[Figure 3: Reordering the layout of the my.monash home channel]](layout.gif)
The presentation style (or colour scheme) is a portal-wide setting, which defines how all your channels will look. We provide four settings which range from very simple, through table-heavy, to CSS-enabled. The CSS-enabled look-and-feel is the one we provide as a default, as it is perhaps the clearest, and uses the least complex HTML.
Profiling allows users to enhance or correct the profile that the portal has of them as a user. Essentially this allows users to see what roles and affiliations the portal has recorded for them, and to adjust and refine this information.
It also allows for tailoring of the presentation of certain parts of the portal, eg. important announcements should be sent by SMS to a mobile phone, instead of by email.
The customisation section has already alluded to the range of resources that can be integrated. The critical part of integration, however, is automating the retrieval of information in a reliable way, to ensure current, relevant information. Nothing is more useless than a stale webpage, except for a stale portal!
Much of the richness of the Monash portal comes from our 'grab and cache' system, which seeks out remote websites, generates a précis of their information and stores the summaries as components for inclusion in people's channels.
This is how we provide local newspapers, local weather and campus-based news for our users, ensuring that their portals are relevant to what is going on around them.
Many sites, having recognised that such information drives traffic to them, are making this easier by providing RSS summaries. RSS [HREF13] is a standard initiated by Netscape for their 'My Netscape' portal. It is a simplified XML fragment describing each of the links. my.monash allows people to directly integrate RSS resources into their portals.
Similarly, a rich amount of information is available in public mailing list archives, many of which use standard archiving methods. Two of the more common ones (MHonArc and MailMan) are supported for direct inclusion, with some commonly used lists preselected into the resource catalogue.
Finally, more sophisticated integration is possible by talking directly to applications, as discussed in the next section.
The portal market is rapidly changing, and many of the services that are necessary in a comprehensive enterprise portal are still immature. A key component of the portal environment is its flexibility in integrating new technologies and infrastructure, taking many small pieces in order to form a cohesive and sophisticated whole.
This allows Monash to choose (and where necessary, develop) best-of-breed solutions to specific problems, rather than await the availability of mature, complete products which seek to be "all things to all people."
Such a model also allows for incremental improvement -- parts that prove to be inadequate or inappropriate can easily be removed with minimal impact on the greater whole, and similarly, new systems can be added without users having to learn entire new products -- instead, they merely receive extensions in existing functionality with which they are already familiar.
A primary system for integration in an enterprise portal is the corporate messaging system, including email and discussion group services. Monash uses the iPlanet SuiteSpot messaging suite, which allows straightforward integration because of its compliance with open, published Internet standards.
The first thing any portal user sees once they've logged in to their portal is a summary of their email, with full access to all their messages (through web-based IMAP clients). Also on the front page and featuring prominently on many channels are discussion groups, integrated from the Collabra discussion group server. Finally, for staff, a summary of their personal calendar is provided from the Calendar server.
For students, one of the most important applications is the student administration system. my.monash integrates with our system (Callista), allowing students to re-enrol and change their enrolment fully online, to change their address details, to view their results/academic history and to receive their exam timetable.
The other major system for students is the online teaching environment. The my.monash portal is intended both to form a significant part of the teaching environment and to integrate other teaching environments. my.monash provides tools such as discussion groups and InterLearn (an iterative learning environment) and integrates with WebCT (the University's recently-adopted supported online courseware system).
One of the features that is provided by many portals is a personal calendar. This can be used to manage a user's appointments and meetings. In a university environment this can be significantly enhanced by linking into existing information systems. For instance, the portal knows what subjects a student studies and what campus she is based on. Using this information, the university-wide timetabling system (Syllabus+ at Monash) could be queried to overlay the lecture times and venues over this student's calendar. The university-wide class scheduling system (Allocate+ at Monash) could also be queried to further overlay workshop / laboratory / tutorial times and venues. Personalised exams schedules are already available to include in such a timetable. Finally, this student could choose to overlay her calendar on those of her friends to see when social events or group sessions could be scheduled.
Portal integration with 'heritage' (what we used to call legacy!) applications can be achieved via thin client delivery of applications running on remote servers. Technology such as Citrix ICA [HREF16] can be delivered to a Web browser via a Java client. In addition, many enterprise legacy client-server applications are moving to provide alternative Web-based interfaces. SAP, for instance, is providing web interfaces for its applications through the mysap.com [HREF21] initiative.
There are two streams of information in a portal -- that which is ``pushed'' by information providers, and information that is ``pulled'' by the user. There is a critical balance in allowing providers to ``push'' information -- if too much information is pushed, it looks like advertising, and the portal ceases to be a vital source of relevant information and becomes electronic junk mail.
The key to this balance lies in the relevance engine, which is the subject of our other paper, so we won't go in to detail here, but essentially, there should be a good match between the interests of the recipient and the category/metadata of the information being pushed. A simple example is our narrowcast service, which allows us to make ``broadcast'' announcements to specific niches of people according to their profile, eg. only Clayton staff are interested in the resurfacing of the Clayton staff carpark.
In terms of pulled information, there are information services and application summaries. Information services include standard portal features such as news, weather and sports. Application summaries are all about giving users ownership of the information the enterprise is managing about them.
An important part of a portal service is allowing individuals access to information that relates to them. A significant aspect to this is integrating applications and displaying the results of recent transactions with those applications.
For students using my.monash, this means providing a historical record of their printing costs, their proxy usage, library loans and holds (with overdue warnings and online renewal), address details (as described above) and mail quotas. Collating all this information in a single point ensures that students are aware what is going on with their information and how to change it.
Finally, there is a combination/meld between pushing and pulling, with services which allow customised filtering on their presentation of information. This includes services such as a unified events calendar, where any individual can insert an event, but must categorise it within a strict set of metadata, which ensures that users only see events of interest to them. Similarly, the library has a journals and database alerts service, which informs researchers of new articles or entries which relate to their nominated fields of interest and expertise.
Having focused initially on integration with messaging, learning and teaching and student administration systems, my.monash is planning to expand its services in support of social clubs, research and staff administration. A few of the systems planned to support some of these areas are discussed briefly below.
An important part of University life is social and sporting clubs. For business, a weak analogy could be drawn with cross-department project teams, which have somewhat similar needs.
The most important service for clubs, societies and other 'non-official' groups is a membership database. Once in place, such a database enables access-controlled online environments for these clubs, including websites, discussion areas, events notifications and online elections.
Similarly, support needs to be provided for group administrators, many of whom are inexperienced in the management of committees with formal budgets and reporting requirements. Online systems can streamline the whole administration process to ensure that group can focus on what they formed for -- sharing their areas of interest.
This support can be provided through an induction process which include access to an 'intranet' (private website) of all the information covered in the induction process, including descriptions of duties and responsibilities. This intranet should also provide some means of document/records management, to facilitate de-briefing / changeover.
For ongoing needs, support should be provided for committee minutes and AGM reports, in application workflow for grants, and online budgeting and auditing assistance.
Committees can be the bane of people's lives, or they can be an efficient means of refining ideas and getting things done. A big part of the difference between these two extremes is in planning for meetings and following through on outcomes.
A simple committee system can greatly facilitate these purposes. A formalised format for agendas and minutes which are stored online in a 'document repository' allows:
my.monash currently provides a very simple committee system, and work is in progress to provide the workflow, scheduling and planning functions described above.
Cisco [HREF17] have shown the value of providing integrated training, progression and remuneration management in an HR portal. Such a system allows staff both to manage their own careers and access corporate resources to assist them in furthering their careers.
Many organisations already offer career support functions, but not in an integrated, easily accessible, remotely manageable way. my.monash hopes to integrate and extend existing resources in order to:
Almost everyone seems to be talking about their company's portal strategy, as products are frantically redeveloped (or just rebadged) as portal toolkits or engines. But if one digs beneath the surface, there is a distinct lack of agreement on what a portal is. In fact, most vendors seem to see portals in terms of their existing strengths as a company.
"Vendors seem to agree only on a high-level description of what an enterprise portal provides: a central, browser-accessible resource of corporate data on an intranet. Beyond that, they are promoting wildly differing ideas about what constitutes an "enterprise portal" product and what features it would provide. Depending on who's doing the talking, the ideal enterprise portal may include functions for document management, knowledge management, Web-based data analysis, or enterprise reporting." [HREF18]
Analysts are divided on whether the trend towards portals is real or just marketing hype. As traditional client-server applications become web-enabled, they will be able to be integrated into enterprise portals and provide more functionality.
In our view, enterprise portals will continue to grow in popularity and use precisely to the same extent that they help knowledge workers to do their work more effectively. A useful portal will be a used portal. Anything else will just be a waste of time and money for all concerned.
Thanks for the many people in the Monash community who continue to work to make my.monash an award-winning success. Special thanks to the Flexible Learning and Teaching Program team, whose efforts ensure that my.monash is well-supported and that associated projects are well-managed to ensure continuing success!
Luh, James C. "'Enterprise Portal' Is New Catch Phrase, But Definitions Vary", Intranet Design Magazine, March, 2000. [HREF18]
Strauss, Howard "How Do You Get Started Building a University Web Portal?", Educause 2000, October, 2000. [HREF19]
Nathan Bailey and Andrew Treloar, © 2001. The authors assign to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The authors also grant a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers and for the document to be published on mirrors on the World Wide Web.