The Evolution of the E-Business Portal

By Colin White

The use of portals is growing rapidly as is the number of portal products. 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 portal technology and presents a flexible framework for deploying portal applications.

The Need for a Portal Framework

Like many information technology (IT) solutions, portal applications can be built from the bottom up or the 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, to rapidly fix business "pain-points" and also to achieve a quick return on investment (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.

Figure 1: Federated Portal Framework

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.

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. 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, 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 portal development kits (PDKs) that enable 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 must also 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 new device type, but rather to provide services and tools in PDKs to allow developers to incorporate new Web devices quickly and easily using technologies such as XML-formatted data, extensible stylesheet language (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:

Personalization services filter business content so that individual portal users only see the content that is of interest to them.

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 meta data, is stored in the portal directory which organizes the meta data 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 meta data to locate and access the associated business content. Meta data 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 regularly scheduled basis (e.g., at the end of each business day) 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 is 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 include calendar sharing, chat and news groups, and real-time conferencing.

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 content store. The portal directory is the cornerstone of a portal because it acts as the road map for the complete domain of business content (i.e., information, applications and expertise) that can be viewed by business users. Documentation, or meta data, 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.

Portal directory entries are typically organized by subject area, and each subject is related to a specific business topic or concept. The business taxonomy that defines this subject area structure is developed during the portal design process and is one of the most important elements of portal development and ongoing maintenance. The categorization manager uses the business rules for this taxonomy in determining the most appropriate subject area with which to associate meta data about business content. The taxonomy rules are evaluated by the categorization manager using information extracted from the business content itself or from the meta data about the business content (application name, file name, Web page URL, author, etc.). Services (e.g., publishing services) and tools that use the portal directory interface can employ the categorization manager to assist in assigning portal directory entries to a suitable subject area.

Products vary significantly in their portal directory and categorization manager capabilities and in the types of meta data they maintain in the portal directory. Some products simply document the name and location of the content, while others support more detailed information about its business meaning and usage. Similarly, some products provide robust automated categorization managers, while others require all categorization to be accomplished manually. Portal directory and categorization manager functionality are key distinguishing factors between products.

The portal content adapters component supplies a set of services for collecting information about business content and for accessing that content. As already discussed, the information about business content that can be accessed via a portal is kept as meta data in the portal directory. Portal adapters can take several forms ­ examples include programmable interfaces, file import and export mechanisms, and automated tools (sometimes called crawlers) that scan business content at regular intervals. A portal may provide adapters for databases and files, business intelligence products, content and document management systems, groupware and office objects (e.g., e-mail, word processing documents, spreadsheets and Web pages) or applications (front-office, back-office and e-business).

Portal content adapters vary in sophistication. Some may consist of a rudimentary generic database or file interface, while others are tightly integrated into the source content (e.g., an e-business commerce application). When selecting products, it is not the number of adapters that are provided by a portal that matters, but the capabilities provided for each adapter. More sophisticated adapters are being added to portal products by vendors. Examples include adapters for interoperability with enterprise application integration (EAI) software, for text mining and for cataloging expertise and tracking relationships between different job skills based on usage data.

Portal developers can add content adapters to portals using the portal development kit. A PDK should provide facilities that enable Java or Microsoft ActiveX wrappers to be written that access business content and present this content and its associated meta data to the portal in the form of an XML-based data stream. The PDK should also be able to support content adapters that can interact with other portal services so that sophisticated vertical portals can be built to handle interrelationships between various types of business content and business processing. A portal content adapter may, for example, need to interact with workflow services so that a vertical portal application can be developed for managing the flow of business content between different portal users. These types of vertical portal applications will be developed by independent software vendors (ISVs) and tailored by individual customers to match business needs. Packaged vertical portal applications built using an open portal development platform significantly reduce the amount of effort required by an organization to implement and integrate a portal.

Most portals interact with the business user via a Web-based interface. The underlying Web services that provide this interface may be contained in the portal infrastructure itself, but products usually employ a separate Web server to handle this processing. The Web server facilities used by portal products vary from simple HTTP listener services to reliance on the Web server for administration and development tools, security and interfaces to back-end business content stores. Although it is important for portal products to provide portability between leading Web servers, it is also crucial, as user volumes build, that products exploit features such as directory services, caching, load balancing and failover in Web application servers.

Portal Evolution

Portal products are rapidly evolving, and the following clear industry trends can be seen in the portal marketplace:

• Support for enterprise transaction applications (legacy systems, front-and back-office application packages, e-business applications) using custom portal content adapters or third-party EAI software.
• Support for a wider range of business information (business intelligence tools, content management systems, database data, office documents, Web information, syndicated data) and expertise using custom portal content adapters.
• The creation of portal development kits that enable IT developers, ISVs and system integrators to add and customize portal adapters for accessing business content. Product examples include Ascential Axielle type manager, Epicentric portal modules, IBM WebSphere Portal Server portlets, Microsoft Web parts, Oracle portlets, Plumtree gadgets, TopTier iViews and Viador portlets. One issue here is that most of the PDKs support documented, but proprietary interfaces which means that adapters cannot be interchanged between products. The Java Apache Project has published an open XML-based portal adapter interface (known as Jetspeed), but few vendors other than IBM support this. Some vendors are working on supporting other vendors' adapters. Plumtree, for example, is working with Microsoft to make Plumtree Gadgets and Microsoft Web parts work in each other's portal environments. TopTier (recently acquired by SAP) has a relationship with Microsoft to enable TopTier iViews to run as Microsoft Web parts.
• Support for a broad range of Web devices including mobile and wireless devices using facilities such as XML and XSL. Examples of products that focus on mobile and wireless support include Corechange Coreport 3g, IBM WebSphere Everyplace Suite and Oracle Oracle9iAS Wireless Edition.
• The integration of portal technologies into Web application and commerce servers. Examples include the BroadVision InfoExchange Portal, IBM WebSphere Portal Server, Oracle Oracle9iAS Server and Sun iPlanet Portal Server.
• The integration of portal technologies into groupware and office solutions. Key examples are the Lotus Knowledge Discovery System, Microsoft SharePoint Portal Server and Correlate K-Maps for both Lotus and Microsoft.
• Enhanced portal product functionality in the areas of security, search services, rules processing, meta data support, workflow and collaboration. Examples of products include Ascential Axielle (meta data management), Microsoft (search and collaboration services), Verity Portal One (search services) and Viador E- Portal (security).
• The integration of portal technology into vertical application packages. Examples of key vendors include Oracle, PeopleSoft and SAP.
• Industry consolidation by product acquisitions and mergers. Examples of recent acquisitions include TopTier (by SAP to form SAP Portals, Inc.) and Sequoia Software (by Citrix Software).

No single portal product currently meets all the requirements of a portal solution, and it is important when evaluating portal products to match product features to application requirements and to select products that provide support for an open portal framework..

Colin White, founder of DataBase Associates, is a leading information technology consultant. White specializes in data warehousing, business intelligence tools and analytic applications, enterprise information portals and database systems. He can be reached at cwhite@databaseassociates.com.