![[Diagram of an enterprise information architecture]](InformationArchitecture.gif)
Nathan Bailey [HREF4], 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
At Monash, the portal team is developing an Enterprise Learning Portal which through profile based personalisation can push references to potentially relevant resources into the portal desktops of all individuals of the University community. The system is based on a set of profile attributes for each community member. The same profile attributes are used in the resource catalogue to define specific, tight target audiences for each resource. A relevance engine matches the resources to each member's profile attributes. The Enterprise Learning Portal learns profile attribute values for individuals and resources and refines the rules of relevance appropriately.
Many other types portals exist and address different issues (eg. search engines, applications and shopping malls).
Throughout this we will draw heavily from the experience and planning of the my.monash portal in service at Monash University since July 1999.
The Enterprise Portal is expected to:
People access the web through a portal for one reason alone -- to access online resources and services. The Enterprise Portal value proposition is simply to provide better access to this content.
Individually personalised content management is the fundamental upon which the portal must function. Other issues are may be showstoppers if not done adequately, or nice features to have, but the content is what the users need.
At Monash we have observed the same thing with the customisation facilities only being used by a minority and these are generally the power users. Average users like the portal because of what it brings together for them by itself and use traditional means (including not at all) of finding and tracking of other online resources.
Profile-oriented Personalisation (PoP) aims to eliminate the need for most individuals to customise their portals in order to access the resources of most relevance to them. And when they find their portals are lacking, they check their profile to make sure it is up to date. Adjusting the profile should permit the portal's relevance engine to find the missing resources.
a doorway or gate etc., especially a large and elaborate one.Based on this definition, an Enterprise Portal should focus on facilitating the delivery of information rather than providing information and services. From the user's point of view, the Enterprise Portal provides an integrated environment with all the required services and systems in a unified interface. But the portal is acting as a proxy, it is the focal point from where everything else is managed.
The model for an Enterprise Portal described in this paper has no end user accessible content of its own. Instead, the focus is on meta-managing the data, describing about resources, access methods and potentially users although user metadata may be better stored in a directory service (eg. LDAP [ HREF7 ]).
There is a danger in providing an Enterprise Portal service to attempt to be "all things to all people", with the risk that it won't be anything to anyone, delivering a mediocre bit of everything rather than excellence in one thing -- a "one stop information shop" that allows seamless management of multiple and diverse systems.
The Information Architecture section later in this paper discusses a view of the online resources needed by enterprise community members, and how personalised views of the resources can be managed.
When developing a portal it is tempting to host new resources that are not yet online. As described above, this temptation needs to be avoided to ensure independence from any one system or suite of systems. Although new resources may physically reside on the same hardware they need to be sufficiently separate so that they can easily be moved to a different system.
This is expected to be a growing area with more sources becoming available providing "up to the minute" information in specific areas.
Within my.monash a variety of these are used with a preference for the RDF format [ HREF10 ]. Monash also incorporates summaries from standard mailing list archives (MHonArc [ HREF11 ] and MailMan [ HREF12 ]) and screen scrapes some published material and republishes it as resources for inclusion in the portal.
Figure 1 provides a view of an Information Architecture used to show the information classes and their interrelationships. It also shows how an enterprise portal can provide an overarching access mechanism for the collation and dissemination of information, resources and services.
Figure 1 - Information Architecture
Monash has many partner organisations with web content of significant value to Monash. These include:
There is also a lot of material which is hosted outside Monash and partners related to Monash activities to which staff and students need access, including:
Some applications provide a Web accessible online presence but others require additional modules to provide this service. Monash has a vision that all business services provided by these applications will be accessible online and is investing significant resources in achieving this through the acquisition and development of web-enabled capability. The resulting online services each have their own URL and appropriate security.
Online services also provide means for community members to enter or modify information such as enrolling in subjects, changing residential addresses, sending email and submitting documents to discussion forums or repositories.
Three classes of access can be defined:
The rules may also contain timing metadata relating to when a resource is valid. For example, the reenrolment service is only valid for part of the year. Rules may also be associated with different presentation agents.
Currently only the web is supported but the architecture permits presentation agents for alternate methods of access such as WAP on mobile phones, IVR over the phone and hand held devices such as palm pilots.
Presentation agents for non-web oriented mechanisms would provide access methods to the same resources with the appropriate form of presentation. Resources based on streaming video or PDF files may be considered unsuitable over WAP but streaming audio may integrate well into IVR.
At Monash, the HR system is used for staff and the student system for students. The data is combined into an LDAP directory. As the portal expands to include the broader community such as alumni and prospective students, new means are required to be the definitive sources of data.
Some portal systems permit and encourage people to update their records in the portal or directory. Where a definitive source for records is available, it is critical that the changes are either propagated to the definitive source is updated rather than a local copy.
Some search engines such as Looksmart and Yahoo have people looking at the site to determine its potential value to target audiences. The problem here is there is only scope for a single value judgement from a general perspective. Value judgements for use in an enterprise portal must be made from a multitude of perspectives once the baseline of some value to somebody has been achieved.
Search engines such as Google perform an automated value judgement based on the number and prominence of sites that link to a page. This saves a lot of the leg work but often the most valuable of material is the most recent and its value declines with age. It takes time for other web page authors to find and link to good material by which time the value may be waning.
The mechanism proposed at Monash is to define and publish a profile attribute vocabulary which is referenced in target audience metadata of each resource to be catalogued by the resource catalogue webcrawler.
Other strategies include:
When users suggest refinements in profile attributes and relevance rules, a value judgement must be made on believing the user. Applying the suggestion to this user's portal is fine but the in the context of propagating the refinement to all other users needs further evaluation.
Stage one will require manual intervention, where someone checks the suggestion to ensure that the benefits are likely to outweigh any detriment and filter out any practical jokes. However, this is not sustainable in the long term.
Stage two provides Slashdot-style "karma" [ HREF13 ] [ HREF14 ] [ HREF15 ] (credibility ratings) for each community member which determines if the suggestion requires manual validation before being propagated to the rest of the community.
Stage three permits limited propagation to a section of the community close to the user who made the suggestion and seeks peer review prior to full propagation.
If Jason always tends to open new browser windows for links then his portal should add the appropriate HTML to launch a new window automatically.
If Alla tends to read world news articles before reading articles about sport, then her local news component should filter the world news upwards and the sports news downwards.
If most first-year Arts view a particular web site (as précised from aggregate proxy data), then this resource should become a default for Arts students.
If I regularly send mail to a couple of friends, then their addresses should be available in a drop list when I compose a new message
This style of refinement is very similar to the MS Office "AutoCorrect" functionality, which does spelling, capitalisation and layout corrections on the fly. If Sam always misspells 'privilege' then the portal could automatically fix this as he sends his message. A list of such corrections can be built up over time, and modified by the user to refine the almost correct or remove the incorrect.
Association-driven relevance allows the portal to automatically learn better associations for you, based on what other people do. People who are members of the darts club are also members of the soccer club -- so when we give a list of clubs for you to join, we highlight the soccer club as especially interesting for you.
People who are postgraduates are most likely interested in the postgraduate research centre and other postgraduate resources, so when they go to the "My.community" channel, they get a postgraduate-specific theme which caters to their specialist needs.
People who are recently new to the University (eg. first year students) probably need a bit of extra help, so the portal has a bit more descriptive information around each component for them, and includes information about orientation (staff or student view) and transition (for recent school leavers).
People who chose these three resources generally also choose that one, so next time we get someone who chooses those three, we'll recommend the forth. Similarly, people who chose those three resources are generally second-year chemical engineers, so lets make them default resources on the home page of second-year chemical engineers (automatically).
People who use the ''My community'' channel frequently also tend to use email and chat frequently, so let's put email and chat on to the My community channel by default (automatically), so it's all in one place.
People who are in South Africa tend not to use the portal during Australian mornings, so lets increase the frequency of updates for their information at other times, but decrease it during the Aussie morning.
People who've been at Monash for many years don't tend to read the Monash corporate information (ie. where our campuses and centres are, and maps to get to them), so let's remove it from their defaults.
For example, John tends to read his email every morning, first thing, but never reads it in the afternoon. When John loads his portal in the morning, email should be at the top, but in the afternoon, it shouldn't even appear on that page (maybe just a link instead).
Hong can't enrol at the moment, so there's no point in making the re-enrolment link prominent for her -- let's drop it to the bottom of her administration links.
Ooh! Enrolment for Angela's faculty closes today, and she hasn't enrolled! Make sure that the link appears at the top of her portal page, and send her an SMS on her mobile phone "Urgent, you must enrol today!!!"
The portal must cope with inherently unreliable subservient systems. For example, some systems still need to have users kicked off during backups. Other systems cannot easily be replicated out of single-point of failure mode (eg. duplicating mail spools could be quite expensive). It is likely to be several generations of thinking in the broader IT community before the majority of systems used by community members are highly available.
At Monash, substantial use of caching is used. This borders on "data warehousing" in some situations where the main system can't cope with the transaction level generated by the number of users.
Short timeouts must be set on requests to subservient systems. When these timeouts are reached, the portal must proceed with whatever data is available. If the subservient system later comes back with the requested data, is needs to be cached for when the user next wants that data (likely to be within a couple of minutes).
Infrastructure reliability is only part of reliability of enterprise portals. It is equally important that the information delivered by the portal and upon which it makes its decisions is well understood.
If someone has the "Breaking news" resource on their portal, the news should be up to date or indicate that it is not (and possibly why not -- eg. the remote site is down). If the portal chooses not to make a resource available to a group of people, this may need to be communicated, lest they think their view of the portal is broken.
To get many of the necessary applications web accessible, the simplest way is often to buy the vendor's portal product. This will lead to large organisations like universities trying to manage many portals. Currently a number of systems have been identified (eg. Student information, Finance/HR, Library, Research, Teaching materials, Community service) and this number is likely to increase with many application vendors assuming they are providing the only portal.
The integration of these portals into a single service for the enterprise, may be more difficult than the underlying application integration issues that the initial use of portals evaded. One portal needs to be the master or umbrella portal and interface to the other portals. This will be a major nightmare for portals that use client side computation such as Java applets.
Two options exist for interchange of profile data:
The peer to peer model is where individual systems pass information between them in a network of peer to peer relationships. The peer to peer model has been the focus of IMS [ HREF18 ] [HREF19] although most of the work can be directly applied to a directory model as well.
Lessons from application integration architecture suggest that the multitude of peer to peer relationships is likely to pose significant overheads particularly with multiple relationship management. Other problems are likely to include many systems working with subsets of the full profile, providing some values while using others.
A difficulty with industry specific specifications such as IMS is that many vendors sell into several different industries and do not provide as comprehensive support as those vendors that work within a single industry. For example, difficulties are likely to be experienced sharing profile information between financial systems, student systems and library systems.
Single sign on may be fine as a goal for a range of low security issues. However with capabilities expanding, a need for security vigilance is critical. Reauthentication potentially with different keys should be enforced whenever a significant change in context or security level is requested by the user. Traditionally this has required the user to type in their old password before being able to change it. With access to an increasing range of resources from multiple organisations available through a single portal, single sign on as a goal needs to be changed. The issues are:
The portal could potentially then manage the security keys for all of those financial institutions with the user no longer knowing their values. This could be of great benefit to some users but with a parallel increase in risk.
The portal provider has also potentially accepted significant risk in offering this service. By intervening in the relationship between the financial institution and the end user, the portal provider becomes a party to any dispute in which the portal played a part.
For example, consider the Amazon-style relevance matching for clubs. Members of religious or political clubs may feel quite violated if their membership is indicated with a statement like "Bill has three interests in common with you, and here's a fourth -- the Satanist club, do you want to join?".
It is imperative that portals always deal with information in aggregate, and that personal usage and profile information only ever be available to the individual. In the increasingly strict legislative environment, many organisations are developing the required privacy policies for their websites. [ HREF17 ] It is quite likely, however, that you will need to make much stronger statements regarding privacy for your portal, to ensure that people feel they can trust that they aren't going to be sold out, either to publish potentially embarrassing information, or to receive junk mail from organisations.
These concerns lead to another personalisation aspect -- a paranoia level, where users can indicate their privacy concern from "free and easy" through to "CIA operative" The free and easy may wish for all their friends to be able to see their personal schedule, whilst CIA operatives would prefer not to even appear in directory listings.
An enterprise portal should never leverage individual data for marketing purposes. In fact, it is the authors' conviction that enterprise portals should carefully moderate any advertising at all. The role of an enterprise portal is to protect and serve the community members. Where users select to receive information, such information can be pushed, but if users ever feel like the portal is providing more junk than needed resources, they will no longer feel "served" and leave in droves.
Although the field is highly dynamic with new products, concepts and strategies continually being developed, and easy quick fixes available to most issues, the Enterprise Portal used by an organisation to deliver online productivity must be reliable and based on sound infrastructure, architecture and standards.
Standards and specifications are only starting to emerge on fundamental issues such as interoperability of profiles, and a lot of work needs to be done on the vocabularies to be used within these standards and specifications.
Organisations working in this field need to be prepared for substantial rework on their systems as the standards emerge if they do not participate in the evolution of the standards.