A Look at Portals Inside and Out

Page 2 of 3

      Bookmark and Share

Portal Scenarios
Portal implementations frequently differ with respect to scope. Some portals are designed to span an entire enterprise (whether they succeed in that goal is another question), while others seek to fulfill a specific—often simpler—business mission, frequently at a departmental level.

To truly differentiate among portal projects (and products) in the marketplace, I’ve outlined seven broad scenarios. Listed roughly from least to most complex:

Web publishing. For enterprises looking to publish content dynamically from a database, portals provide a dynamic web application out of the box, complete with a content model, caching tools, and usually personalization and search facilities as well. The portal may well also bundle common “utility” web applications, like forums and surveys.

Web development. This is similar to the use case above, but with an emphasis on representing dynamic services rather than dynamic content. For example, many portal products offer pre-packaged applications out of the box (e.g., people-finders and other utility applications) that can be modified using portal tools. Perhaps more importantly, most portals typically ship with different frameworks for developing custom applications more rapidly than would be the case with a naked application server.

Collaboration portal. Web-based portals can allow geographically disparate teams to work together on projects, handing out assignments, collaborating on tasks, reviewing documents, and tracking progress. Combined with web conferencing, instant messaging, and perhaps wiki software, this can reduce the need to meet physically and allow project staff to work more efficiently.

Self-service portal. Self-service portals come in all varieties. The most well-known are public portals for improving customer care by enabling customers to help themselves and receive service on their terms, improving loyalty and likely saving your enterprise money in the bargain, inasmuch as self-service offers an alternative to more costly traditional ways of servicing customers. A key value-add of portal software here is its ability to aggregate data and content from multiple sources, obviating the customer’s need to track down information across multiple sites (possibly logging in multiple times).

Enterprise intranet. Intranets are as varied as the businesses that launch them. Yet all of them attempt to help employees work more effectively and efficiently. An intranet may contain multiple specialized portal applications, including an HR intranet, managerial dashboard, and sales intranet.

Ebusiness portal. An ebusiness portal enables an enterprise to extend portal access to external trading partners, suppliers, and customers. This in turn helps improve business relationships, communication, and ultimately the bottom line. The concept is similar to that of a self-service portal, as ebusiness portals seek to raise the value and lower the costs of transactions. However, ebusiness portals typically come with ecommerce capabilities for processing transactions, a product catalogue, specialized partner content, and often supply chain integration.

Enterprise integration. This is the opposite extreme of our first scenario, dynamic web publishing. Enterprise integration portals go way beyond simple web publishing to piece together enterprise systems to achieve greater efficiency and agility. Two logical integration architectures for integrating applications exist: direct point-to-point connections and middleware-based integration, with most portals using middleware, such as an application server to do the actual integration.

Despite a near-persistent (and very reasonable) desire across enterprises to consolidate vendors and applications, it is neither always easy nor wise to use the same enterprise portal package for different scenarios. Different portal types and information paradigms can carry significantly divergent requirements. Even if they share portlets or access to underlying datasets, the end user’s needs may well be quite different. Those scenarios should be analyzed before the enterprise can make sound judgments about where and how to consolidate portal efforts.

If your requirements across portals or locations diverge substantially, you will have to review your options. You may still be able to use the same portal product successfully, but you will find that no software is going to handle divergent use cases as well as you would like. You’ll likely have to compromise. Alternatively, you may come to see a need to license multiple portal products, or simply deploy and implement the same product separately to meet the disparate needs. At the end of the day, this is the point: meeting business needs.

Page 2 of 3