Sun logo      Previous      Contents      Index      Next     

Sun ONE Portal Server 6.2 Deployment Guide

Chapter 6
Understanding the Portal Deployment Life Cycle

This chapter provides on overview of the portal deployment life cycle. Use this chapter to help you develop your overall portal deployment project plan.

This chapter contains the following sections:

Overview of the Portal Deployment Life Cycle

Deploying a complex product such as Sun™ ONE Portal Server software requires considerable planning effort. To simplify this effort, the following high-level steps break down the portal deployment life cycle into more manageable phases:

  1. Creating the deployment plan
  2. Creating the high-level portal design
  3. Creating the low-level portal design
  4. Implementing and verifying the trial portal
  5. Rolling out the trial portal to a production deployment
  6. Ongoing monitoring and tuning of the portal

The following sections in this chapter discuss these deployment phases in more detail.

Creating the Portal Deployment Plan

Your portal deployment plan is essentially a task list that assigns resources to specific tasks and deliverables. The initial project plan provides important task-level information regarding the steps and order of implementation. Compare your known business and technical requirements against the project plan to look for proper alignment, order of execution, appropriate duration, and any tasks that you might have overlooked.

Though each organization will differ in its own project plans and project management approaches, there are similar elements that should be included in a portal project plan for the deployment to be effective. Ultimately, your project plan will become a functional roadmap for your deployment.


The portal deployment plan should be read and understood by all system stakeholders with an interest in the detailed workings of the system. Most importantly, this includes those individuals who are building the system and those who need to use it to carry out their business responsibilities.

Your portal project plan answers questions such as:

See Appendix B, "Portal Deployment Worksheets"” for a list of the key portal design tasks. This list, in the form of a worksheet, will assist you with developing your project plan. Though these tasks will vary depending on your organization and the scale of each deployment, the worksheet presented in the appendix represents the most common phases and tasks encountered.

Defining Project Objectives and Scope

As the first step in planning your portal deployment, you define your project objectives (what you want to accomplish) and scope (what you plan to include and exclude).

When you define your project objectives, specify your organization’s business goals and how Portal Server helps to meet those goals. For example, you might have a business goal of having users authenticate once and only once to be able to use web applications and data. Portal Server meets this goal by making use of the SSO API contained within the Sun™ ONE Identity Server product. By being clear in your project’s objectives and scope, can better manage expectations that arise during the project.

In addition to making sure that your project plan clearly states project objectives and defines its scope, provide methods and ways to measure successes and the overall progress. For example, you might use a web site within your organization to track portal deployment status, or send out regular deployment status emails to stakeholders.

When defining a portal project’s scope, keep in mind the following demands and requirements that your organization might have:

When you scope your portal solution, you must meet the above requirements while at the same time balancing these requirements with a solution that is deliverable within a reasonable timeframe. The ultimate goal of the project objectives and scope is to provide hardware and software recommendations, an initial man-hour estimate for all work, and a recommendation for the network layout.


To run an efficient project, carefully prioritize the requirements, based on input from all stakeholders, and manage its scope. Too many projects suffer from developers working on features the developer finds interesting and challenging, rather than focusing early on tasks that mitigate risk in the project or stabilize the architecture of the application.

To make sure that you resolve or mitigate risks in a project as early as possible, develop your system incrementally. Carefully choose requirements for each increment that alleviate known risks in the project. To do so, you need to negotiate the scope (of each iteration) with the stakeholders of the project. This typically requires good skills in managing expectations of the output from the project in its different phases. You also need to have control of the sources of requirements, of how the deliverables of the project look, as well as the development process itself.

Understanding the High-level and Low-level Portal Design

The high-level and low-level design steps of the portal deployment life cycle are where you create the actual portal design or architecture. The high- and low-level designs represent the complete set of designs for your deployment.

In designing your portal architecture, start by describing your high-level architecture and implementation, which arise out of your business requirements and sizing needs, as identified in Chapter 4, "Analyzing Your Portal Requirements" and Chapter 5, "Sizing Your Portal". The high-level architecture is intended to communicate the architecture of the system and provide the basis for developing the detailed design for your portal solution.

The low-level design gets into specifics, including such aspects as your complex of servers, networking considerations, content design and implementation, Identity Server architecture, and application integration.

See Chapter 7, "Creating Your Portal Design" for more information on the high- and low-level design concepts.

Implementing and Verifying the Portal

After you have completed your high- and low-level portal design, you begin the implementation and verification stages of deploying your portal. This stage involves development, testing, validating against your performance criteria, and taking all this into account to implement a redesign of the portal architecture, if necessary.

Content Aggregation

Content aggregation is a portal feature that enables content from various disparate sources to be combined and presented to users in a single interface, known as the Portal Desktop. The Portal Server providers produce the content in the form of channels in the Portal Desktop.

One of the most important aspects of a portal is its ability to integrate applications, services, and content. This functionality includes the ability to embed non-persistent information, such as stock quotes, through the portal, and to run applications within, or deliver them through, a portal.

Items to consider when developing your portal content include:

The availability and response time of the servers providing the content (and source of the content) will impact the Portal Desktop in the following ways:

Content Management

Content management functionality is critical to managing your portal content. Content management covers the full life cycle of publishing information to the portal, ranging from content creation and collaboration to workflow, version control, staging, and publishing of new and updated content to the portal. While content is most often internal data that is useful to portal users, it can also be external news feeds and data sources. Because the portal content might come from many different sources, content management functionality is required to prevent erroneous or unapproved content being placed on the portal.


Portal Server does not provide tools for creating and adding portal content. You must obtain a third-party product to perform content management. See "Content and Document Management ISVs" for more information.

Source Control

Though not a requirement for Portal Server, using source control software is recommended. Source control software provides a systematic way of controlling a complex migration and development process. Using source control provides your organization with a definitive snapshot of the production system for any given code release, and an easy way of reverting to a previous release level if you encounter problems.

Source control software also ensures that a file’s source is not changed improperly. This includes making sure that your developers are using the latest version of the file, and that no two developers edit the file at the same time, resulting in overwritten changes. Source control also ensures that the files are not deleted, moved, or otherwise changed in such a way that they cannot be rolled back to the original files.

Add all portal files that you will modify to the source control system, including configuration, HTML, JavaServer Pages™ files, and Java™ source code files. Portal Server does not provide a source control system, so you will need to purchase one, if your organization does not already use one.


When you set up your source control directory structure, use one that is similar to the UNIX® directory structure where the portal software is installed. Also, create “editions” or “tag” your source control tree when deploying content to a production system. This way you have complete control over the system and know exactly what state the system is in.

Testing the Portal

Your overall portal testing strategy involves performing a series of complementary testing activities in a phased approach on all system components. This testing strategy includes the following:

Analyzing Performance Test Results

Perform the following types of analysis on your performance test results:

Conducting the Portal Trial

After you test your portal design in a non-production environment, such as a lab, you will want to conduct a trial portal deployment in your production environment. A trial portal deployment usually involves a limited number of users. Conducting a trial run of your portal deployment minimizes risks that you might encounter in a full-scale portal deployment.

Benefits of conducting a trial include:

During the trial, users must be able to provide feedback on how the portal works for them. You can use this feedback to fix any problems that might arise and to develop an idea in terms of what kind of support you will need for the full-scale deployment. A portal trial will ultimately lead you to conclude that a full deployment can proceed, or that you need to spend more time resolving issues.

In general, you structure your trial into phases, to further minimize risks during deployment.

Conducting the trial process is iterative, and involves the following general steps:

  1. Creating the trial deployment plan
  2. Deploying the trial
  3. Supporting and monitoring the trial
  4. Obtaining feedback
  5. Modifying portal design; if necessary, repeating steps 2 - 4
  6. Moving to full-scale deployment

A plan for your trial portal addresses the following:

Moving to a Production Environment

The last phase of of the deployment life cycle is moving from a trial environment to a production environment. Moving to a production environment occurs after your have thoroughly tested your portal and operated it as a trial deployment to test and refine your design.

Factors to consider in your move to a production environment include:

Monitoring and Tuning

Monitoring and tuning your portal deployment is an ongoing, cyclical process, in which you look for bottlenecks and other performance issues.

With monitoring and tuning your portal, keep the following points in mind:

See the Sun ONE Portal Server 6.2 Installation Guide for more information on the configuration parameters for optimizing the performance and capacity of Portal Server. The perftune script (located in the portal-server-install-root/SUNWps/bin directory), bundled with Portal Server, automates most of the tuning process discussed in this guide. See Chapter 8, "Monitoring and Tuning Your Portal", in this guide, for additional monitoring and tuning information.

Documenting the Portal

A comprehensive set of documentation on how your portal functions is an important mechanism to increasing the supportability of the system. The different areas that need to be documented to create a supportable solution include:

The run book outlines troubleshooting techniques as well as the deployment life cycle. Make this book available during the training and transfer of knowledge phase of the project.


Do not wait until the end of the deployment project, when time and money are usually running short, to begin this documentation phase. Documenting your portal should occur as an ongoing activity throughout the entire deployment.

Previous      Contents      Index      Next     

Copyright 2003 Sun Microsystems, Inc. All rights reserved.