The Evolution of the e-Business Portal (Part I)

by Colin White

April 2002

The use of portals is growing rapidly and so too is the number of portal products to choose from, and as the portal marketplace becomes saturated, watch for an increasing number of product acquisitions and failures. Given the volatility of the portal industry, it is important that organizations build a flexible portal framework that can adapt to marketplace changes and product advancements. A portal framework will also help with integration issues as portal technology is absorbed into related software areas such as Web application servers, e-business packages and enterprise application integration software. To help you to sort out the current marketplace confusion and plan your portal implementation, this article reviews the current state of the art in portal technology and presents a flexible framework for deploying portal applications.

The Need for a Portal Framework

Like many IT solutions, portal applications can be built bottom-up or top-down. The bottom-up approach encourages rapid deployment by allowing each group or department within a company to implement its own portal without having to consider issues such as integrating portal applications into an overall enterprise architecture, or creating portal business terminology that is consistent throughout the organization. The top-down approach takes the opposite tack by carefully evaluating corporate business requirements and defining a portal framework that allows portal applications to be integrated into a single enterprise-wide solution. Which approach is better? The answer will vary by organization, and will depend largely on IT budgets and the ability of the IT department to enforce corporate-wide standards. Ideally, a combination of both approaches should be used. Individual portal projects should be encouraged to gain experience with portal implementation, and to rapidly fix business “pain-points” and also to achieve a quick ROI. At the same time these point solutions should, without significant integration effort, be able to be plugged into a federated portal framework as shown in Figure 1. As mentioned earlier, such a framework is also essential to be able to adapt to changing marketplace forces and product enhancements.

To support a federated portal framework, products must provide a development platform of open interfaces and services that enable developers to customize both the portal user’s Web interface and the portal adapters that are used to access business information and applications. We will take a more detailed look at requirements for a portal development platform later in this article.

Figure 1. Federated Portal Framework

The Move Toward Supporting e-Business

Most companies focus initially on building an internal corporate portal that gives employees and business users a personalized view of information on the corporate intranet, human resource data, etc. Growth in the use of e-business, however, has led to many organizations integrating portal technology into their e-business systems and applications. An e-business portal enables a company to extend portal access to external trading partners, suppliers and clients, which helps improve business relationships and communication.

The move toward the use of e-business portals has led portal vendors to add support for additional business content such as business intelligence, e-mail, office documents, expertise, and e-business and back- and front-office applications. As vendors evolve their portal products it becomes increasingly difficult for them to support the wide range of services and business content that their customers require. To solve this problem many vendors are now providing a portal development kit (PDK) that enables developers to extend portal products to suit their business and technology requirements (see Figure 2).

Figure 2. Portal Development Kit

More Than Just a Web Interface

The main goal of a portal is to give each user a personalized and integrated view of corporate information and applications. To achieve this goal a portal must offer more than just a simple Web interface to business content, it also must have a rich set of services for collecting, categorizing, integrating, and personalizing this content. These services should have open interfaces that can be used in conjunction with the portal development kit to both customize and extend the portal environment. These interfaces together with the PDK form the cornerstone of a portal development platform. The main components of an ideal portal development platform are shown Figure 3.

Figure 3. e-Business Portal Development Platform

The presentation services component acts as the main interface between the portal user and the portal itself. At present, most portals interact with portal users via HTML sent to desktop client computers running Web browsers such as Microsoft Internet Explorer or Netscape Communicator. In some products, ActiveX or Java is used to enhance the appearance of the user interface. Most portal products allow the look and feel of the interface to be tailored to match the needs of the user. The growth in the use of mobile and wireless devices will require portal products to support a broad range of Web devices. The key to solving this requirement is not to continuously add support for each device type as it enters the market, but rather to provide services and tools in a portal development kit to allow developers to incorporate new Web devices quickly and easily using technologies such as XML-formatted data, XSL style sheets, and industry-standard wireless protocols.

The user services component controls how business users (and other portal components) locate and access business content. Key services provided by this component are as follows:

• Personalization services filter business content so that individual portal users only see the content they are interested in.
• Security services enforce the security standards of the organization by ensuring that users can only view the business content they are authorized to see. This aspect of a portal will become increasingly more important as the depth and breadth of business content increases, and as this content is made available to external users.
• Publishing services provide an interactive mechanism for business users to document the location and meaning of business content in the portal so that it can be shared and accessed by other portal users. This documentation, or metadata, is stored in the portal directory, which organizes the metadata into subject areas for ease of access. Some products support the relocation of published content to a shared portal content store. This capability is particularly useful when publishing business information that is stored on a user’s private desktop computer – the information can be moved to a shared and managed environment.
• Access and search services help the portal user find and access business content. The user browses the portal directory to find items of interest, and then uses the information in the metadata to locate and access the associated business content. Metadata browsing can be done by navigating the portal directory, or by using search services to query the portal directory. Some products also provide search engines that can search the actual business content in addition to the entries in the portal directory.
• Subscription and notification services enable portal users to have business information delivered to them on a regular scheduled basis (at the end of each business day, for example), or to be notified (via e-mail or by messages on the user’s portal home page) when new business content is made available or existing content changed. The schedules and notification rules for each user’s subscriptions are stored in the user’s profile in the portal directory.
• Collaboration services offer tools that allow portal users to communicate with each other. Examples here include calendar sharing, chat and news groups, real-time conferencing, and so forth. 
• Workflow services enable portal users to define and manage a set of interrelated business tasks. Each task in the workflow is triggered when a previous related task in the workflow is completed. Tasks can use portal services to access business information, run applications, send messages, and create operational transactions.

The content management component manages the portal directory and the portal content store. The portal directory is the cornerstone of a portal, since it acts as the roadmap to the complete domain of business content (i.e., information, applications, and expertise) that can be viewed by business users. Documentation, or metadata, about this business content is maintained in the portal directory using an interface that enables both portal and external services and tools to create and modify portal directory entries.