The overhead associated with the simultaneous maintenance of separate and distinct employee, partner and customer Web sites coupled with the demand for greater Web-enabled and portable site functionality is leading many companies toward one ubiquitous solution: the enterprise portal. Initially employed as primarily inward-facing knowledge and content management systems, the latest generation of portal products includes the application integration and Web services capabilities that have long been demanded. The successfully deployed enterprise portal will be the single entry point for collaboration, information dissemination and communication, application functionality and interactive capabilities within and without the corporate entity – all provided in an efficient and centralized manner that has previously been unavailable.

Recent Internet, extranet and intranet services may attempt to emulate the features of an enterprise portal, but they lack advantages that only a true portal framework provides. The major benefits of an enterprise portal that combine to distinguish it from these other non- portal services are:

Knowledge/Content Management and Collaboration. This includes the ability to organize content in intelligent, searchable taxonomies with expiration, versioning and access control features.

Application Integration. The portal is a Web desktop serving as the gateway to all corporate applications. Single sign-on ability provides seamless movement between the portal and applications. Integrated business intelligence functions can be used to present dashboard type reporting and event notification services.

Business Process Management. Workflow is reduced and simplified by executing workflow processes, such as invoice approval and HR tasks, via the portal.

Branding and Customization. A portal framework meets the corporation's need to implement entity-wide, synchronized branding while allowing sub-organizations and individual users to customize the presentation and content of their individual portal interfaces.

Security. A robust security structure allows administrators to assign selective access to portal features and functionality, enabling the same portal deployment to provide different content to diverse users.

Administration. Remote administration is available via a Web interface. Additionally, administrative capabilities can be dispersed among several users, alleviating the administrative burden often placed on a small group of people.

Step One: Planning

The initial temptation might be to immediately execute a single portal deployment serving all employees, partners and customers. Although it is technically possible for one portal to meet the differing needs of all users via the flexible content security that a portal provides, it may initially be difficult to secure approval for the time and financial commitments that such a massive undertaking requires. Therefore, an iterative approach to enterprise portal deployment is a good alternative. (See Figure 1.)

Figure 1: Enterprise Portal Deployment Life Cycle

Iterative deployment has the advantage of generating return on investment (ROI) more rapidly by providing singularly useful components of the total enterprise portal in successive implementations. ROI can be defined in terms of both hard and soft fiscal gains. An example of hard gains would be the ability of the corporation to better take advantage of vendor discounts as a result of streamlining invoice approval via the portal. A less tangible, or soft, benefit might be increased customer satisfaction.

With portal development, iterations can be thought of in two ways. First, iterations can be defined in terms of sub- portals for entities that have similar needs – a customer portal, a partner portal and an employee portal. The second way to consider iterations is in terms of iterative deployments within each sub-portal.

In the first case, as each sub-portal is successively implemented, it becomes part of a growing enterprise portal. It is then accessible either from one sign-on page with content depending on user identity or as one of several autonomous portals available via links from a "master" page. In either case, content and infrastructure can be shared among the sub-portals, resulting in economies of scale.

Secondly, iterations may represent deployments within each sub- portal with each iteration adding functionality. Rolling out a sub-portal with a subset of the necessary functionality may speed ROI; but user acceptance may suffer, as the portal does not immediately fulfill the goal of providing its users with a single access point. It is critical to achieve balance between ROI realization and providing a useful product that successfully gains user acceptance.

Once the scope of the portal is defined, requirements must be gathered. There are two categories of requirements: functional and technical. Functional requirements include content, degree of content dynamicism, applications, customization and accessibility features. Choice of operating systems, .NET versus J2EE, database platform and application integration capabilities are examples of necessary technical considerations, some of which may already be defined by existing corporate policies. There is a strong correlation between the number of sources consulted for requirements and the acceptance of the deployed portal.

Step Two: Product Selection

With requirements established, vendor evaluation can begin. Arguably the most important step in portal deployment, the selection of a portal product determines the potential to ultimately realize a successful enterprise portal. Building a portal, rather than purchasing one, is an option that should be considered during the vendor evaluation process. When requirements gathering reveals little need for robust portal functionality or indicates the need for highly customized and proprietary functionality not available for purchase, building a portal may be the best option. However, the decision to build entails its own costs and time investment and should be thoroughly compared to the findings of the vendor evaluations.

The increasing demand for portal solutions has precipitated the emergence of a multitude of portal products. The major evaluation points are:

Architecture: This is one of the most important evaluation points. If product evaluation reveals that significant changes to the functionality will be necessary to meet requirements, such as augmenting the delivered security feature, it will be essential that the vendor provide at least some access to the portal's API. Some vendors open the majority of their API to their customers for modifications; some have a completely closed architecture requiring that the vendor make changes. Look for interface flexibility such that portal pages can be modified to place logos or content anywhere and the vendor logo can be completely removed. Consider carefully not only the current, but also possible future needs and the impact they may have on architecture requirements.

Scalability: "Adapters" (names vary by vendor) integrate applications into the portal. Most vendors will deliver with their product, usually at an additional cost, prebuilt adapters to many popular applications such as SAP, PeopleSoft and BusinessObjects. It is important to note that if these applications have been heavily modified, the associated adapters may not work. If the appropriate adapter is not available and enterprise application integration (EAI) tools do not satisfy the requirement or are not an option due to cost, then adapters must be custom built. Custom building adapters will involve the use of the portal's software development kit (SDK). The most flexible SDKs are based on common technologies, such as Java. If a vendor provides a proprietary SDK, or does not offer one, its customers must employ technologies such as common gateway interface (CGI) and active server page (ASP).

Price: Excluding hardware, the cost of the portal product itself is only a fraction of the total cost of deploying and maintaining a portal. Implementation costs – integrating applications, customizations, security and branding ­ can run several times the cost of licenses. There are obvious costs associated with engaging outside consultants, but there are also opportunity costs or "back- fill" costs that need to be considered with the use of internal resources. Also, once the portal is deployed and operational, the content and infrastructure will need to be maintained, and some level of development will be ongoing. Application service provider models, now offered by some portal vendors, may be evaluated as an alternative. Finally, determine whether it will be necessary to purchase any technologies that the portal will require but not provide and evaluate the associated costs. These might include single sign-on capability and robust content management packages (versioning, taxonomies, collaboration, etc.).

For these reasons, there is no such thing as a free portal. Some vendors offer a "free" portal product with the purchase of supporting or related products. Although the portal products offered by these companies have merit, the implementation and maintenance costs still need to be examined. Additionally, there is free-ware available which can be used to build a simple portal; but, again, be sure to consider the tasks associated with deployment.

Vendor Viability: Relatively, the portal market is still fairly young, and the long-term players have yet to fully emerge. The major points to consider in this area are:

  • Financial stability.
  • Years in existence.
  • Number of implementations and market share.
  • Adaptability of the product to many technologies. (This is the issue of the openness of the architecture and how much of the portal framework is proprietary.)
  • Partnerships (vertical and horizontal market alignment).

Miscellaneous: Aside from these major points, there are some secondary factors to consider as well. What is the availability and pricing structure of Web services? Is the security structure flexible enough? Does the delegated administration model fit the requirements? What kind of customizations can the user make? Does the vendor offer extensive support and training? Is the vendor willing to provide an evaluation version? Support, or development of support, for existing and emerging interfaces such as voice recognition should be offered. Finally, it is important to talk with developers who have already implemented the portal to learn about their experiences.

Step Three: Development and Implementation

If the prior steps have been properly executed, there should be few surprises during the implementation. Knowing the capabilities of the selected product, the resources with the necessary skills should already be on staff. Back-end issues, such as hardware, load balancing, automated failover, task monitoring and task prioritization should all have been resolved at this point.

With the intense focus on development and implementation tasks, it is often easy to overlook having the actual content ready and available for the deployment. Efforts to create and format content to populate the portal should proceed in parallel with the development process. The development team will provide the applications and Web services, but other content that will make the portal the truly omnipresent point of contact (such as HR manuals, product information and company directories) will have to be contributed by other sources. Plans must be made to regularly refresh and update content on an ongoing basis to create "stickiness" and drive utilization.

The primary and most time- consuming priority for development is application integration. Applications for which adapters are prebuilt by the portal vendor require minimal effort, testing and perhaps only minor modifications. Custom-built adapters will be the most difficult. Adapters can integrate applications in two ways:

Seamless Integration. With seamless integration, the user is not aware they are launching a non-portal application. The interface of the application is completely wrapped by the portal framework. Fonts, colors and style of application interaction all follow the scheme of the portal. The more difficult of the two integration options, this involves setting up a messaging scheme in order for the portal to be able to utilize the functionality of the back-end application. Obviously complications can occur, especially if the application architecture is not exposed.

Screen Scrape or Link Out. Either of these methods may be used with applications that already have a Web-enabled interface, and the end result of both methods is the same. The native interface of the application is retained within the portal. The application interface is presented in a window or frame within the portal display, or a hypertext link is placed inside the portal to open the application in an external window. Although this method is often faster and easier to implement, it does create a disjointed appearance.

With either method, applications that require user identity information can present challenges in enacting single sign-on features with the portal. Depending on company security policies and the communication scheme between the portal and the applications, these problems can be overcome by coding a password synchronization mechanism or by purchasing a third-party tool.

The other two significant efforts of development and implementation are to apply security and brand the portal. As with content, the parameters and requirements for branding should be communicated to the appropriate parties early on so deployment will not be delayed. Applying security includes loading all users and specifying group membership, applying content and activity privileges of those groups, and setting up the administrator and delegated administrator hierarchy.

Step Four: Rollout

All types of users should test the portal prior to rollout. A well-designed and well-built portal will require minimal training, usually provided in a one- page user guide. For most portal deployments, the vast number of users makes formal user training too costly and time-consuming to be practical. Some portal products will be delivered with robust "help" links; but if not, custom help screens should be created.

Getting people to actually use the portal is the major challenge during rollout. Why try something new when the old way works? Immediately disabling access to the previous methods of doing business is ill advised as problems may arise early in the portal rollout. Therefore, users need to be given a reason to start using the portal. The biggest draw will be the content. The portal should contain new, fresh content not available anywhere else. Continually updated content such as incentive program news, fiscal results and HR information will help build user-ship. Making relevant and popular Web services available also encourages use. Finally, the biggest adversary to any deployment is instability. Nothing drives users away faster than a portal that does not always work.

A feedback mechanism, facilitated by the portal, is extremely valuable in improving current content as well as planning future additions. Continued success of the portal relies on response to user suggestions. Tracking usage is a must. Knowing what content and features are popular, and which are not, is important not only to the development team, but also to those responsible for the content. Usage monitoring tools may be available from the portal vendor, can be custom built or can be purchased from third-party vendors.

Providing a single point of entry to all company resources and communications results in more efficient dissemination of information and allows employees, partners and customers to collaborate and interact more effectively. Deploying a successful enterprise portal is a complex task. However, with careful planning, as well as the required resource and financial commitments, an enterprise portal will achieve results with value far exceeding the project costs.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access