What To Do Until Your Portal Arrives
Building an enterprise portal is an expensive, time-consuming, culture-wrenching endeavor. Despite these difficulties, it's essential that all colleges and universities build one as soon as possible. In the long run an enterprise portal will save a university a great deal of money and increase the effectiveness of the entire school community. If the money or staff to start a portal project is not available today, there are some inexpensive steps that can be taken right now that will make building your portal much easier when you can afford to get it going. Each of these steps will provide your users and your IT staff immediate benefits—even if you never build a portal.
Planning
Abraham Lincoln said that if he had eight hours to chop down a tree, he'd spend
the first six sharpening his ax. Even if you can't start building a portal in
the near future, start planning now. A portal is a new concept. It will take
users a long time to get used to the radical ideas of user-centric Web pages,
shared university data, and users that are empowered to manage their own information.
It took about 60 years to realize that sitting in a thin aluminum tube moving
600 miles per hour six miles above the Earth's surface was a good way to get
from Washington to Paris. Portals will probably be accepted more quickly. By
having your portal team in place and having a comprehensive portal plan ready
you'll be able to move quickly as soon as culture and finances allow the start
of your portal project.
Your portal planning must include high-level commitment, user involvement, defined sponsors and stakeholders, and the goals for your project—including having a university-wide portal with single sign-on.
Define Your Audience
Determine who uses your home page—students, faculty, staff, prospective students,
visiting scholars, parents of students, and others—and how each group uses it.
Once you know who your audience is and what they want, rebuild your home page
with appropriate links for each different constituency. Carnegie Mellon University
(www.cmu.edu) has special links
on its home page for prospective students, faculty visitors, researchers, alumni,
and many others. Each of these links takes a visitor to a Web page tailored
to that constituency. It's not a portal, but it is a vast improvement over a
typical home page. Understanding that different groups of users need different
information from the Web and learning what those differences are is essential
for building your portal.
Build Portal-Like Pages
Real portals have information in user-centric channels. Channels are hard to
create and are best left for when you actually build a portal. But you should
build role-specific, constituency Web pages now. Your library Web pages, for
example, are probably built for a general audience. How would they look if only
undergraduates, faculty, or staff used them? If you think that everyone wants
identical Web pages from the library, Chemistry department, and so forth, you
need to get out of your office and discover what's really going on. When you
build your portal, you'll be ready to change these role-specific pages into
portal channels.
Ownership and Interfaces
Redundant data may be a necessary evil, but if an employee name is kept in 37
different databases, which one is the authority for the name? If the name changes
in one place, will it get changed in all the others? A university-wide data
dictionary needs to be built and the ownership and attributes of every data
element needs to be assigned.
Application-to-application interfaces must be replaced with application-to-hub-to-application interfaces. In an application-to-application interface, an application that needs data must figure out where to get the data and it must know the interface to that data. Chances are, the interface to each data source will be different and will frequently change. If an application needs to update a data element, it must update it in all the places the data element exists, or must know which one to update so that all are eventually in synch. In an application-to-hub-to-application model, all requests for data and the updating of data are made to a common hub. The interface to the hub is always the same and it changes infrequently. The hub is responsible for updating data elements, keeping them in synch.
Start Building Profiles
Now that you understand your data, start understanding your users. What are
the needs of departmental managers, tenured faculty, football players, and so
forth? A profile is a database that contains the characteristics of different
constituencies. Your portal will have to build customized pages based on profiles
of each constituency, but even before you have a portal, knowing your users
will help you deliver better IT services to them.
Authentication
Plan for single sign-on. Reduce the number of different ways users can authenticate.
Install a password synchronization program such as P-Synch (www.psynch.com).
Consider PKI, electronic signatures, and biometrics. Allow temporary authentication
by giving outside users an ID and password—your system will recognize these
outsiders when they return and will steer them to the most appropriate data.
Your university and your users need the cutting-edge services a portal can
provide. Planning is always essential before you take a whack at a portal or
a tree. Having a collection of sharp tools ready will be useful even if the
tree falls over or you decide to hang a hammock on it rather than cutting it
down.
