There are many, many different kinds of portals. The Merriam-Webster's Online Dictionary contains five definitions for portal as a noun, ranging from a door to the entrance of a bridge and ending at "a site serving as a guide or point of entry to the World Wide Web." This article (and the portal it is published on) is only concerned with web portals, and the readers of this article (should be) only concerned with two types of portals: portals that succeed and portals that fail. No one purposely goes out to build a portal that will fail, yet it happens time and time again. To understand some of the key reasons portals fail, it will probably help to know a little bit about how portals evolved to what they are today.
A Brief (Unofficial) History of Portals
Web portals began as a way to simplify the Internet for new users. Just as the word "portal" has evolved to encompass broader and richer meanings since its 14th century roots, the web portal has expanded in functionality and complexity. Many of the early portal successes were based on little more than a collection of categorized bookmarks and have expanded to become a network of sites almost as large as the early Internet they intended to simplify.
Portal technologies evolved, too. The first portals were simply very large and very well-designed web sites. The portal approach was rapidly adopted for intranets and extranets. Software companies were born with the (ironic) goal of making it easier for their customers to enter the arena of building portals. Then, the bigger software companies began to provide portal software as well. For a brief period, portals (other than the early successes open to everyone and continuing to grow) fell out of favor due to a lack of standards. As standards were established, the companies that made only portal products were bought by the software giants, moved to open source, or disappeared. Once the technologies were standardized, everyone had to have a portal (again).
Now that the technologies are standard and there are lots of successful portals to
copy emulate, it should be easy to build a successful portal. In the immortal words of Wayne and Garth, "Not!" This leads to the key topic of this article: What not to do.
1. Designing from Back to Front
Part of the Wikipedia web portal entry says "It is designed to use distributed applications, different numbers and types of middleware and hardware to provide services from a number of different sources." Depending on who reads this description, it could be interpreted to mean that portals are driven by the needs of backend services. If a backend service is a good candidate for a portal, it is either because it is hard to find, hard to use, or related to other services that have their own access points. Simply providing access to such services through a service does not make them usable or useful. If an application is added to a portal without thought to who will use it and how they want to use it, the user will either continue to use it the way he did before or not use it at all. By definition, a portal that is not used has failed.
Avoid this pitfall by designing your portal from the front end to the back. Most of changes necessary to build a usable portal can be done within the portal framework itself, and when making changes to backend services that don't lend themselves well to being exposed in a portal appear to be the only way, it is generally a case where the service is not being used to its full potential because of this already.
2. Too Much Too Soon
The early portals that succeeded all share one common evolutionary path. They began with a small number (usually one) of services that were well designed and highly desirable to users. Many new portal projects start with the goal of aggregating everything from one common point of access. This may be a goal with a high probability of success if there is a binding theme to "everything," such as the audience (customers, employees, vendors). Trying to go from zero to goal will generally lead to a crash. Contributing factors to this common failure strategy include poor site structure, user-vicious applications, performance issues, and manageability failures. It only takes one of these factors the make a portal a failure and a single release containing a large number of features will almost always lead to at least one of these issues.
There are indications that can tip you off before this becomes the death of your portal. Requirements take more than three meetings for a given topic. People joining the portal project mid-stream will find it difficult to understand the goals of the project or how things work. Developers will begin working long hours. Quality engineers will have difficulty defining test cases or test cases will not make sense to the development team.
3. Leaving Maintenance Planning for Post Production
Portal maintenance includes activities such as updating portlets, managing user access and entitlements, static content updates, integration testing, performance tuning, navigation enhancements, and dozens of other tasks. Because most portals are built on top of a portal framework, it is often thought that these things are magically managed out-of-the-box, or that it will be so simple that planning for these activities is a waste of time. These lines of reasoning lead straight to portals that are never used, or fall over when used by everyone who needs to, or are used furiously at first and then forgotten, or different people making the same changes multiple times or different people making conflicting changes or a few people burning out from overwork.
Portals are intended to simplify life for both users and IT. They can only fulfill these good intentions if they are planned for. Simple does not mean self-maintaining. Yet. During your planning stages, be sure to consider what will change, how often, by whom, and why? It is also important to avoid the "everything will change" trap and the "business (or IT) will manage everything" fallacies. One leads to a lot of extra work and complexity and the other leads to finger-pointing and disappointment.
4. Complexity for the Sake of Consistency
Many project plans correctly tackle the most complicated functionality early because they impose the most risk to the project. Complicated functionality often requires the use of complex design patterns to ensure extensibility, maintainability, and performance. It is also a common practice to enforce the use of consistent development approaches to improve time to market, reduce training, and avoid knowledge islands. All of these are important goals. Taken to the extreme, the pursuit of these goals will lead the portal in the exact opposite direction.
Complex solutions applied to simple functionality will result in exactly the opposite result of when they are applied where necessary. A maintenance developer has to learn the functionality of multiple classes and have deep experience to work on something that could have been contained in a single file. A new (simple) application takes three times as long (six times if you use TDD) to write and has more potential points of failure. Performance begins to degrade as the same amount of system resources are allocated on the server for a "Hello World" level portlet as an intricate BI data aggregation portlet. Solution patterns are meant to solve a particular problem and become an anti-pattern when applied to the wrong problem.