Uberportal (Super-Portal)
- Uri Ginzborg
- Aug 1, 2006
- 3 min read
Multiple portals are a common reality in medium-sized organizations and certainly in large ones. Generally, the solution for using several portals simultaneously is the trivial solution of multiple entry points (in professional jargon: "stove-pipes"). An Uberportal is an architecture for creating a unified portal, connecting all entry points to a single location.
From a Gartner article (http://www.gartner.com), a detailed explanation: Multiple portals are a common reality in medium-sized and large organizations. Several reasons can be listed for this reality:
Portals are marketed as OEM products alongside additional hardware/software systems;
The eternal quarrel between Java solution supporters and the rest (for example, .NET supporters).
On the surface, this reality wouldn't necessarily have to be problematic if there were a single standard that all portal manufacturers respected. Usually, it's impossible to share components from one portal to another in a way that respects authorization mechanisms, service directories, or user preferences across portals. The Uberportal architecture presents a solution to this problem, at least until the introduction of the new standard for Portal Federation toward the end of 2005. "Uber" is a German word meaning "over" (or "above"). This combination of words refers to an "over" component that unifies the rest of the "subordinate" components into a single portal. The main principles of the architecture are:
The Uberportal is the only entry point to all other portals in the organization (the employee's homepage)
An Uberportal is not a tool that can be purchased "out of the box" but must be built to fit the organization's systems.
The best software products for implementing an "Uberportal" are software products with open architecture that are service-oriented and standardized. To implement such a portal sharing, you need to know how to share the following elements:
Service Directory
Authorization mechanisms (Security)
User preferences (Personalization Data)
Structural information (Metadata)
Portal applications (Portlets)
Since no tool currently knows how to unify all these elements (due to the lack of standards), the Uberportal architecture seems merely theoretical. However, it can still be made practical by defining the concept of a "minimal Uberportal." A Minimalist Uberportal is a type of Uberportal that serves only as an entry door to other portals. In practice, it activates the subordinate portals in a separate window. For a portal to be a minimalist Uberportal, it must implement the following elements:
A rationally unified service directory (Rationalized directory service).
SSO (Single Sign On): Authentication to this portal will implement authentication to all other portals and will be the only authentication in the system.
Implementation of user preferences at the page level of Uberportal (not required to include the settings defined at Uberportal level for subordinate portals).
Entry to portals will be via hyperlinks or tabs.
When closing the window after finishing browsing in a "subordinate" portal, the user will return to the appropriate screen in the Uberportal.
Until standards are established and until software companies implement them, a minimalist Uberportal is recommended for any organization whose employees use more than one organizational portal.
Thanks: Thank you to Ranit Zakatzer for obtaining sources for this information.
Comments