Enterprise portals are no longer just content delivery mechanisms. Portals have become platforms for accessing information and consolidating and integrating IT infrastructure. In the past few years, however, autonomous and decentralized departments have been deploying their own enterprise portals, most of which have been unable to work together. The analyst firm, Gartner, refers to this trend as “stovepipe portals.” The proliferation of these independent portals has made sharing information more difficult. To solve this problem, companies must be able to deploy federated portals and adopt standards-based platforms that can aid information unification.

Federated Portals

Gartner defines federated portals as decentralized networks of portals working together. Most portal solutions today are deployed in a single portal server, wherein the portlets are installed in the same machine and are hardwired to the same server

Based on Gartner’s definition, a federated portal permits portlets to reside on different machines across the organization. These remote portlets may even be other portal installations, referencing other portlets.

There are several advantages to the federated portal approach including the following:

• No local installation of portlets is required, meaning reduced downtime for production systems, particularly when new or updated portlets have to be installed
• Portlets can be shared by several different portals, enabling departments to share information and applications
• When upgrading to a new version of the portal software, the portlets do not need to be re-installed or re-configured
• The portal becomes interoperable with other portals. In fact, the portal only needs to communicate with other portal interfaces enabling the sharing of different portlet technologies including Java, C#, and .Net

In addition, federated portals can support remote portlet providers. Remote portlet providers are related portlets grouped together in a separate server or a portlet container.

The advantages of a federated portal with remote portlet providers include:

• Searching for new portlets becomes easier, because related portlets are grouped together
• Developers can concentrate on writing portlet code, instead of the interface to the portal, because remote providers abstract the communication layer between portlets and the portal
• Portlet developers can apply default settings to sets of portlets and have the option of changing settings on individual portlets, resulting in more efficient portlet development