![[Example of current portal integration paths]](portal-integration.gif)
Nathan Bailey [HREF1], Manager, Flexible Learning and Teaching Program, Information Technology Services [HREF2], PO Box 3A, Monash University [HREF3], Victoria, 3800. Nathan.Bailey@its.monash.edu
portals, enterprise information portal, university, homogeneity, applications, services, user-centred design, customer-oriented websites, disintegrated environment, unified environment
For too long, IT has provided applications which are focused on specific data niches, rather than services which are oriented to the user's needs. Users have to switch between many different applications that manage various bits of data in order to do a larger task. How much easier it would be if all these applications worked together to provide a seamless workflow in the way that the user needed to use them?! After all, users just want to find the information they need and to action it in the way they need to, quickly and easily
It is the intention of an enterprise information portal to be the "glue" that joins the many diverse offerings of an organisation into one cohesive whole -- the portal becomes the great homogeniser, encapsulating, simplifying and personalising all the heterogeneity of the organisation and its many applications into a unified, user-centric service.
"The network is the computer" -- so say Sun Microsystems, in declaring their vision of a powerful, interconnected environment made up of many small, independent systems and yet providing one holistic experience. The 80s saw a proliferation of applications, with large and small companies responding to a broad range of general and specific niche needs. Each application had its own design, nomenclature and interfaces, both for the user and the administrator/technical staff. Even though the advent of Windows saw a certain amount of commonality in the user experience, users remained very aware of the different applications they were using, and backroom administrators were all too aware of the nightmare of trying to get systems to talk to each other, with batch jobs and data conversion scripts all tied together with pieces of string that broke with every upgrade.
The advent of standards such as XML-RPC, SOAP and other generic "business function" oriented APIs is responding to the need for applications to all work together nicely, which makes the backroom administrators happy -- but what about the users? All too often they are still forced to learn how to use a dozen different applications with two-dozen different workflows and a whole set of nomenclature that is different from what the organisation and the industry actually uses.
The typical enterprise resource planning system is a great example of this. Most managers merely want a few simple reports and the ability to easily approve various purchases proposed by their subordinates. But all too often an implementation requires these already busy crucial decision makers to become full power users of this very complex application, learning its ins and outs and ways of presenting information that are only approximately relevant to the way the organisation actually does things.
Often a simple transaction results in interactions with multiple unconnected systems using different standards and even different environments. Consider a simple hardware purchase:
At Monash, if someone wants to purchase a laptop, they would first go to the procurement website to find out who our approved suppliers are, what the recommended models are, etc. Next, they would need to contact the actual supplier to confirm these details, make any adjustments to the specifications, create a requisition in SAP, receive approval and raise a purchase order. There is no mechanism that indicates the status of this purchase (e.g. like UPS/FedEx parcel tracking) so if the purchaser wants to check on the order, they must contact the supplier directly. The laptop is finally delivered to the appropriate individual, but this is far from the end of the process.
Next, the machine must be registered for the network (in 'AddHost', our DNS management system) and the installation of local software may need to be arranged (another process with little electronic support). Hopefully you already have a network port arranged, but if not, that is another entirely separate process that follows a completely different set of workflows. Being a capital asset, the laptop must then be entered in the asset management system, although this system offers little management beyond a simple register of ownership correlating to a barcode on the laptop.
With approximately 15,000 devices on the Monash network, and the average lifespan of a PC being three years, this process is probably being followed a couple of dozen times each day, and yet all these steps remain painfully, separate and distinct -- heterogeneous instead of homogeneous.
So how does this all relate to an enterprise portal? The goal of an enterprise portal is to provide a one-stop service shop for the organisation, focussed specifically to each individual's needs. With traditional applications, it would be completely cost-prohibitive to provide a customised user experience for each user. With an enterprise portal, providing such an experience is not only possible, it's easy.
A huge change focus of applications is just on the horizon, and it is emerging on the enterprise portals of leading organisations. The simple point is -- users don't need to know about applications. If a complex workflow like the above interacts with 15 different systems, they need never know! All they need to do is follow the standard "Get a new laptop" workflow, and all the questions that are relevant to them in their role will be asked and answered (and questions requiring input from others will be routed to those people for attention).
Suddenly, we are able to offer service-oriented services, instead of application-oriented services, with each service being specifically customised and streamlined for that particular user. We are saving time, not just for the user in completing the task they are trying to do, but in training and support, since the user never needs to become familiar with the various screens, workflows and nomenclature of the underlying applications that combine to provide that service.
How can such a utopian goal be achieved? By combining the power of the back-end integration offered by web-smart applications together with the power of enterprise portals and LDAP-based profiling and access control. The second part of this article describes two such "service-oriented" workflows that are being established at Monash University, in the delivery of teaching units. These workflows cater to learning and teaching from a student and a staff perspective.
The concept of an enterprise information portal is a recent one, building on the sense of 'portal' first established by companies such as Netscape (my.netscape.com) and Yahoo (my.yahoo.com). The major difference between these public portals and an enterprise information portal is the audience -- the enterprise portal is focused on the employees, customers and associates of the company, rather than the general public.
More recently, companies have started calling their web interfaces 'portals.' Whilst it is useful to see each application becoming more and more personalised and customisable for each user, it is not particularly useful for users to have 15 different portals they need to access to do their daily work. One way of looking at the enterprise information portal is as a meta-portal that integrates all these application-specification portals.
The intention of an enterprise information portal is to:
A critical part of this process is ensuring that users do not have to learn many different user interfaces or paradigms in order to complete the above tasks. In the same vein, the portal should be service-focused, rather than application focused. This may mean combining information from multiple applications in a transparent way in order to provide one unified service. Users need not know if they have used 100 different applications, or merely one, in order to complete the business process they wanted to complete.
Users are generally provided with three levels of access to web-based applications via Monash's portal:
Summary information is provided to allow a broad view of all the information flows relevant to that user. Information that requires an action from the user will form part of their workflow. Users can choose to receive notification about such events in up to four different ways:
The summary workflow component reports on the number of outstanding items requiring attention, and provides one-click access to respond to those items in the 'general user' view of that service.
The general user view provides a personalised, customisable view of the service for the user that is specific to the Monash environment. This means it may draw on information from other sources, or join several applications together to provide one logical service. This merging process is transparent to the user, they just use the service to complete their transactions or retrieve information. Personalisation ensures that the user receives the relevant information and access that is due to their role, departmental affiliations and other working commitments. Customisation allows users to refine the default presentation of the service and its information be more relevant and concise for that user.
Finally, power users require full access to the actual applications that are involved in providing the service. Generally, this is a much more limited audience than those who are general users (probably less than 20%). By shielding general users from the real application, application-specific training costs can be reduced and applications can be changed transparently while services continue to provide the same functions in the same way.
These power users should be able to transfer seamlessly into the full application from either the summary view or the general user view. Seamlessly means that the user is taken directly to the part of the application they are dealing with, without needing to authenticate or navigate through various intermediary screens.
This tiered level of service should only be provided for the commonly used functions -- we don't want to attempt to reimplement the whole application! For those power users who have needs that go beyond the common user, access to the full application is required, and should be provided.
This above process can most easily be displayed by using a service all of us would be familiar with -- messaging. Most of us are used to having to regularly process our email inbox, and many are familiar with an instant messaging program of some kind. But ultimately, all these programs are producing messages that we need to deal with. Instead of having to switch to half a dozen different applications just to respond to each message, it would be much easier to have a unified messaging environment. The unified environment could look something like this:
Messaging Subject Sender Date/Time Type Priority New students changes Gabriel Norris 7th May, 2002 Proposed meeting H New student proposal Duane Staehli 10:00am, 10th May, 2002 M The file you sent... Beau Zlatkovic 10:12am, 10th May, 2002 Instant message H - Di James 10:14am, 10th May, 2002 Voicemail L - Anita Dutt 11:35am, 10th May, 2002 Fax L [ Show all... ]
Although I expect it would look a lot better if a graphic designer did it :-) Presumably the type of message would be indicated with a small icon (and obligatory accompanying ALT text :-) rather than the full text. Sorting (shown by date here) could be configured to be priority, time, author, etc. depending on how you prefer to respond to messages.
Clicking on the message would allow you to reply to it in a reply window, with the appropriate dressings -- an email would include things like Subject and Cc/Bcc, whereas an instant message would just require the recipients and the text of the message. The user can now manage all their messages as an integrated whole, replying, storing and deleting them as appropriate, and only having to think about their specific nature when the context requires it (e.g. extra options for reply).
This example provides insight into how separate environments can be synthesised into a more meaningful and accessible whole, but perhaps doesn't communicate the value of such a unified environment. This value can best be demonstrated by a logically simple process known as studying (or teaching) a unit at University. This 'simple' process involves access to dozens of different applications -- applications which were designed to support and facilitate the learning and teaching process, but by their very heterogeneity, can end up obstructing it.
At the earliest stage, a prospective student visits the University, and expresses certain interests or preferences. The University has an opportunity to show how well it can cater to these desires with the courses and offerings it presents. Hopefully the student chooses to follow through this initial, tentative relationship with a concrete enrolment into a course. This is a process of marketing, and is often addressed through a prospective student's portal.
Having selected the course, some units will be mandatory, and some elective. In choosing a unit, the student may choose from a range of resources, ranging from official publications such as the unit handbooks, and online course materials through to less official ones such as teaching staff home pages and student comments in online forums and publications such as the Counter Faculty Handbook.
The timetable will also play an important role in unit selection, with students needing to be able to balance their study commitments with work commitments and social commitments. Students are increasingly giving attention to the development of a community service CV that compliments their work and educational qualifications, so all this scheduling information needs to be available to students.
Having selected a particular offering of a unit, the student may need to further refine their enrolment for particular activities within that unit, such as lecture, tutorial and laboratory streams.
Next, the actual coursework component of the unit commences, with students needing to interact with a broad range of resources across a range of technologies, including everything from print-based resources, online courseware, digitised journals, magazines and books, audio and video lectures and other multimedia teaching resources.
Throughout their interaction with these various resources, students will also need to be assessed in various activities across various systems, including both online assessment activities and the electronic submission and subsequent marking of assignments. These marks need to be recorded and disseminated back to the student.
An exam (with associated review of resources such as digitised previous exams) will conclude the assessment of the unit, and the teaching department will collate and possibly moderate the cumulative assessment into a final mark that is recorded in the student records system, and released to the student on a pre-defined date.
This is a generalisation of the life-cycle of a student's interaction with a unit. In following the above path, they have interacted with at least 10 or 15 different enterprise-wide applications, as well as any number of unit or department-specific applications that support learning and teaching activities.
The key question here is -- did the student know that? Did they know that they were using services provided by such broadly different areas as CeLTS [HREF4], the Library [HREF5], Student and Staff Services [HREF6], ITS [HREF7] and the Faculties [HREF8]? Or did it come across as one, single, seamless experience that they felt was well-supported in a cohesive way?
From a staff perspective, unit management begins with a concept, an idea that needs to be developed into a full unit that fits into a course or a range of courses. The idea needs to be built up with various resources, including a business case and costings. The proposal is workflowed through various key roles within the faculty and then through to Education committee, where the outcome is recorded.
Part of this planning process includes the preparation of a description that becomes the unit handbook entry, a key resource for students in their selection of units, and in turn, the scheduling of the unit.
In terms of scheduling, class sizes need to be estimated and various activities need to be scheduled into associated teaching facilities that have the required capacity and facilities. Meanwhile, the actual course materials need to be prepared.
In preparing course materials, the teaching staff need to co-ordinate across a wide range of University areas, requesting content development support from CeLTS, specific journal, book and database resources to be requisitioned in the Library, and instances of the unit to be created on a broad range of teaching systems, including WebCT [HREF9], WebFace ASS [HREF10], InterLearn [HREF11], MESS [HREF12], QuestionMark and/or personal and departmental web pages.
Similarly, assessment needs to be managed, and marks need to be recorded. There is currently no central system to record interim marks, although many departments have internal systems that record the results of tutorials, laboratories, quizzes and assignments. These results are then coalesced into a final result that is entered in to the student records system.
In parallel, a review process ensures that the unit content, teaching and facilities are of the quality and depth that students expect, so students are requested to respond to a specific unit survey, with the results being centrally recorded and disseminated to the appropriate teaching staff/departments. This information informs the future development of the unit, coming back to the start of the lifecycle for teaching staff's management of a unit.
Information needs to be managed across all these systems, co-ordinated by teaching staff and associated support staff. The current situation is far from homogeneous, but these processes are slowly being drawn together as online services, with the content being managed through a central content and learning objects management system.
Clearly, there is still a long way to go to provide the unified, user-oriented homogeneity being described. One of the key aims of the portal is to make this experience seamless, for everyone. Essentially, students and staff should be workflowed through this learning and teaching process, with the capacity to jump forward and back as they please, and to ask support questions that are managed through a single point of service that can dispatch them to various areas within the University for response.
For the University, this will save on training, maintenance and support costs. It is prohibitive to train students to use applications, not only because of their short tenure (as little as one unit) but also because of their wildly different backgrounds and experience. But even for staff, the process of having to become proficient at a dozen different applications when their needs are fairly simple and consistent seems wasteful.
And when a better application arises (being more cost or resource efficient), the service can be transparently migrated to the new application, without users ever being aware of it. Similarly, we can trim away those bits of the application that we don't want our users to see and be confused by -- or even those we don't want them accidentally changing!
For the user, instead of seeing a multitude of different applications provided by different areas with different support structures -- i.e. a fragmented University providing a fragmented service -- they see a well-organised, cohesive University that lets them manage the information they need to manage, in the way they need to manage it.
This should not stifle innovation or independence. The intention is that anyone can contribute to this seamless environment, inserting their particular development into the workflow at the point or points that appear to be most relevant.
Moreover, it raises the profile of all services, providing better returns on investment for every development. Instead of some new or more obscure system being hidden away, people will be able to find all the relevant options that they are seeking, and choose. Internal services will be better utilised and better integrated with other services.
In essence, the value proposition is this:
I know what the University provides that is relevant to me. I can find it, I can manage it, I can get help for it, and I can do all of that without having to know where it came from, how it works, and where all the various bits of information are stored and managed. I can do what I want, quickly and easily. The value of Monash services is high, because they are accessible to me, oriented toward me, meaningful to me. A very heterogeneous organisation provides me with a very homogeneous experience. A diversified global organisation can still provide a specific, customer-centered service.
And how do we do it? By focusing on the services that users want, rather than the applications that are required to build and provide those services, and the various organisational units that provide those applications.
To respond to these needs, we need to consider the various workflows that staff and students participate in, and how to best align the organisation's processes and systems to those needs.
In developing new systems, it is critical that we not only solve the immediate business need, but also provide the flexibility to reuse that solution in solving other needs. Our vision must be to provide a continually growing set of building blocks that can be rearranged in whatever different ways provide the best service for that particular user.
Monash's portal is currently being enhanced to better respond to this need, allowing departments and divisions to develop their own applications that can become building blocks in larger business processes.
Obviously there is still a lot of development required to achieved the seamless, service-oriented workflows being aspired to, but with management buy-in, careful vendor selection, ingenious back-system integration and a thorough user-centered design, the one-stop service point of the enterprise portal is making a whole new leap in productivity gains.
So now you may be convinced that this is a worthy objective, but perhaps you are wondering how it can be achieved? We need to be able to sew the various applications together, pulling functions from each application in order to provide a unified process that is user-centric. There are various ways to 'pull' functions from applications into a portal environment, but generally they can be broken down into four styles: XML/XSLT, APIs, direct access and HTTP access ('screen scraping').
The simplest and most effective method is for applications to provide data in XML documents and accompanying XSLT stylesheets (that can be customised) to transform this data into HTML. This allows the portal to transform the data and merge it with other data streams (to present it in an easy-to-use, Monash-oriented service) or to précis it (to present in summaries such as the workflow 'dashboard' summary).
The second most preferable integration path is through generic APIs that allow information and transactions to be requested, without exposing the business logic (i.e. so the application can maintain its integrity). This method allows full customisation of the application, and integration with other services, but takes more work than the XML method, since it requires us to design and implement a user interface, rather than merely refining an existing one. 'Web services' are very promising is this regard, exposing business functions from one application for another application to use.
A lesser form of integration is through access the application's data store directly. This approach has all the advantages of the API method, but with the added danger of impacting on the application's integrity, by changing data into a form that the application does not expect or otherwise messing with business logic.
HTTP access (or 'screen scraping', as it is sometimes called) is essentially using software to pretend to be a user with a web browser, i.e. accessing the web application, getting the information and then parsing the information out of the web page). HTTP access provides the benefit of complying with the business logic, but, depending on the formatting of the HTML, may require a great deal of work. It needs similar transforms to that of the API/SQL approaches, but with the added expensive of having to redo the HTML parsing work when a subsequent release changes the web interface.
The (LDAP) directory service is the central backbone of the University's IT infrastructure. It provides a single, authoritative source for identification, authentication and profile information, such as department, role or systems access. Having a strong directory orientation for corporate applications provides a number of key benefits in providing a homogeneous environment:
The easiest way to pass authentication between applications is using a form of ticket-based authentication. The first application verifies the authentication and passes a ''ticket'' to the second application, indicating this is a valid user. For simple applications, a valid ticket is all that is required. More complex applications may require a special ticket that includes the credentials (in order to verify subsequent access controls, for example). In either case, all that is required is an agreed protocol for exchanging and verifying tickets.
An encrypted ticket is essentially a piece of data that contains username, password (encrypted), timestamp and a checksum, all encrypted (simple tickets would not need to include the password). This data can then be read, decrypted and verified (using the checksum) by the second application.
The following diagram shows some examples of current integration paths (some still in development):
The client, using a web browser (Netscape), accesses Monash's enterprise information portal, 'my.monash'. They authenticate using their credentials recorded in the (LDAP) directory service. This service also indicates which systems they have access to, so they might be able to submit a leave form to our ERP, or update a course on our courseware system, or view the status of a call in our HelpDesk system, or review summary information from other web resources.
All of this information is homogenised by the portal into a set of information and services that is meaningful to that user, so they can quickly log in, find what they need, change it if required, and log out again -- from anywhere on (or off) campus.
Monash University's portal is accessible at http://my.monash.edu/ and the support team can be contacted at portal-enquiries@monash.edu.
Nathan Bailey, © 2002. The author assigns to Southern Cross University and other educational and non-profit institutions a non-exclusive license 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 license 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.