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.

comments powered by Disqus