Mr. Grammar Says ...

Abuse of the term "portal" has caused stakeholders to have inaccurate expectations about Web site complexity and costs. Organizations need to specify whether portal projects involve enterprise portal frameworks and true portal principles to paint a clearer picture of business benefits and costs.

META Trend: By 2004, portal frameworks will become the centerpiece of a delivery infrastructure that acts as a fulcrum to aggregate reusable application, content, analytical, and collaboration components for highly dynamic user interfaces. By 2005, organizations will exploit portal frameworks to deliver contextual business workspaces, enabled via maturing XML and Web service standards. Through 2007, portal vendors will increasingly leverage enterprise infrastructure services.

Despite years of maturation of the portal market, vendors and corporate Web site project owners still seem to be abusing the term “portal,” using it to mean the Web site equivalent of “newfangled.” As with “knowledge management” before it, hype and linguistic abuse of the term “portal” have turned it into a dirty word in some organizations. This is unfortunate because the underlying portal concepts have proven valuable and represent best practices for interfaces and integration aimed at end-user consumption. This is also unfortunate because the vendors in the portal market have valuable product to offer with significant potential return on investment that will be overlooked if the term is vague, becomes associated with large-scale failures in other organizations, or is simply another area of technology where hype drives overinvestment.

The term “portal” started as a vague reference to Web sites with collections of links and has become only more vague over the years - as vendors tried to latch onto a term with budget dollars and as project managers wanted their projects to look good on their resumes. META Group defines portal interfaces as contextual interfaces. To be contextual, they must use personalization and dynamic page assembly to deliver customized information. This is a current best practice for Web user interfaces - it does not make sense to design a one-size-fits-all interface for all kinds of users when thin-client interfaces and dynamic page assembly engines are readily available. For personalization to be effective, the portal must have access to a wide range of meta-tagged content and applications, and must dynamically pick a small subset of this content based on the user’s profile. Dynamic Web pages made up of configurable screen real estate also require a particular form of application integration (portlets), which can pass context into an application and return information that can be formatted and presented to an end user.

In 2003/04, the portal market will see 20% of the players exit the market as the luster of the term “portal” diminishes. By 2005, “portal” will settle into maturity as the ability to profit from the term decreases. However, the underlying technology and concepts of enterprise portal frameworks will remain viable through 2007, after which portal and composite application frameworks will have merged and become indistinguishable.

Because of this linguistic abuse, we believe the term "portal" has lost its meaning. Using the word “portal” without a noun is generally too vague to be useful. For example, the answer to the question “How much does a portal cost?” could be “six times greater” if the person asking the question means “portal project” or “portal product.” The answer to the question “How many portals should an organization have?” could be “one” if the person asking the question means “portal framework,” or “hundreds” if the person means “portal sites.” Put linguistically, any use of the word “portal” as a noun rather than an adjective should be considered too vague to be useful (see Figure 1).

The most important definition to understand is “portal framework.” Portal frameworks provide a pre-integrated set of services that are used to build portal interfaces. Identity management, personalization, page assembly, stylesheets, search, taxonomy, content management, usage tracking, application integration, single sign-on, and collaboration all play important roles in portal frameworks, which may either provide or help integrate these technologies. An organization may have any number of portal sites (i.e., the HR portal, the sales portal, the project XYZ portal), but only one portal framework that was used to build them. Organizations that will be developing more than three to five sites with portal interfaces (most organizations fit into this category) should develop or, preferably, purchase a portal framework that can be leveraged for all the sites.

To be more specific, the term “enterprise portal framework” (EPF) encompasses all types of functionality (e.g., collaboration, content management), departments (e.g., HR, sales, divisions), and constituencies (e.g., executives, call center agents, customers, partners). All the vendors tracked in META Group’s Enterprise Portal METAspectrumSM are EPFs. It is important to determine whether a portal project is specifically an EPF project, because EPFs have a recognized scope of work addressed directly by vendors and systems integrators that have implemented them enough times to generate a set of best practices, processes, recognized business benefits, and pricing history. If a project is a portal poseur (e.g., a new extranet project that simply makes a few self-help applications available to suppliers, but has no personalization capabilities or dynamic home pages), the body of EPF best practices, benefits, or pricing comparisons may not apply. In addition, non-EPF projects should steer clear of EPF products, because they will appear overly expensive or complex if most of their functionality (e.g., profiling, personalization engine, content management) will not be utilized or if they are only going to be used for a single small site.

Other portal terms include:

• Portal interface: A contextual, dynamic interface. This is a best-practice Web user interface.
• Portal project: The scope of work required to put together a portal. This may include application integration, taxonomy creation, any number of infrastructure subprojects (e.g., installing a single sign-on tool, selecting a content management tool), or even new application programming, depending on the scope of the project.
• Portal product: A box of software labeled "portal."
• Portlet: A portal adapter that connects an application to a portal, standardized in JSR 168.
• Horizontal portals (e.g., collaboration portal, reporting portal): A portal written for one specific type of functionality that spans vertical boundaries (to be used across the company).
• Vertical portals (e.g., sales portal, Project 123 portal): A portal written for a specific audience that spans horizontal boundaries (combines many types of functionality).
• Enterprise portal: A portal that spans horizontal and vertical dimensions.
• Internet/public portal: An Internet site that links to a large number of other sites (e.g., Yahoo, Excite).

Bottom Line: Organizations should determine whether portal projects truly involve enterprise portal frameworks before applying portal best practices, processes, recognized business benefits, pricing history, and portal framework products. This is to avoid potentially damaging consequences longer term by failing to meet business and budget expectations.

META Group originally published this article on 17 September 2003.