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.

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:

Creating the deployment plan

Creating the high-level portal design

Creating the low-level portal design

Implementing and verifying the trial portal

Rolling out the trial portal to a production deployment

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.



Note	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.

Are the tasks in the appropriate order?

Are the staff resources appropriate?

Is the method of integrating third-party products to support the overall solution appropriate?

What is the approach to integrating your existing applications and clients with the portal?

Have you established reasonable milestones along with signoffs from the appropriate stakeholders?

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:

Delivery of a portal solution to meet today’s business objectives

Best performance

High availability

Scalability

Straight-forward, easy deployment

No single point of failure

Delivery of the right capacity to meet future growth

Delivery of enough capacity to meet above normal peak

Easy migrations and upgrades to future releases

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.



Tip	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.

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.

Container and channel display profile definitions

Whether to use static or dynamic content

Content feeds

Caching

Content licensing and permissions

Personalization

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:

Channels might appear without data.

The loading, and overall performance, of the Portal Desktop can be affected if the response of content servers is slow.

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.



Note	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.



Tip	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:

Unit testing—Performed by a developers to ensure that modules they develop are working per the design document.

Functional testing—Performed by business test owners and technical test owners to ensure that combinations of individually unit-tested pieces of code and basic functionality perform as they were designed to, as they are combined into a complete subsystem. This testing phase is performed within the application, interface, and infrastructure component boundaries.

Integration testing—Performed by business test owners and technical test owners to ensure that there is proper interoperability between subsystems. In addition, cross platform business processes are tested to ascertain they work according to specifications. This testing phase is performed across the boundaries of multiple applications, interfaces, and infrastructure components.

User acceptance testing—Performed by business test owners to verify that all requirements are met by the system, prior to sign-off.

Performance and stress testing—Performed by stress testing owners using a load-testing tool. Load balancing and failover are tested at this time.

Security testing—Performed by an organization’s security group to verify that users can access only those functions and data that they have permissions for, and to verify that only those users with access to the systems, applications, and data are permitted to access them.

Analyzing Performance Test Results

How channel response times degrade under increasing server load—When the server load is light, response times can be acceptable. However, as the load increases, performance usually drops off. Comparing a light load test with a heavy load test shows if there is a problem in the channel design.

How different profile types react under the same load—These test results show how the addition of specific channels introduces latency. The average page return time between tests with the same concurrent user loads should produce similar numbers. If significant time discrepancies appear between tests using different profiles, this identifies a potential problem area. Expect small increases in the average page return time between profiles because additional information is being retrieved and rendered each time the customized page is displayed.

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.

Verification that your design works in the production environment as expected

Confirmation that your design meets your organization’s business requirements

Experience in the deployment life cycle with installation, configuration, and customization of the product

Ability to document and revise production deployment documentation, such as a “run book”

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:

Creating the trial deployment plan

Deploying the trial

Supporting and monitoring the trial

Obtaining feedback

Modifying portal design; if necessary, repeating steps 2 - 4

Moving to full-scale deployment

Scope and objectives—Use specific objectives that your trial needs to meet. Also, identify criteria to gauge the trial’s success.

Who is participating—Establish the appropriate selection criteria to decide which users you want to participate in the trial. Choose users who are typical of your organization.

Training for participants—Before the trial begins, decide how and when to train your participants. Be sure to identify your training resources.

Support plan—Address who in your organization will provide support for the trial, to what level that support extends, and how users will report problems and seek resolution.

How you want to communicate trial status—Describe how the trial participants will receive information prior to the start of the trial, and how status reports about the trial will be delivered.

Rollback plan—Develop the rollback procedures needed in case the trial runs into problems or fails. Include criteria for when to use the rollback plan, and possibly establish levels of severity for potential problems.

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.

Staging

Quality assurance

Using change control

Managing the site

Monitoring and tuning

Documenting the portal

Monitoring and Tuning

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

Beginning with the trial portal, define a baseline performance for your deployment, before you add in the full complexity of the project.

Using this initial benchmark, define the transaction volume your organization is committed to supporting in the short term and in the long run.

Determine whether your current physical infrastructure is capable of supporting the transaction volume requirement you’ve defined. Identify which services will be the first to max out as you increase the activity to the portal. This will indicate the amount of headroom you have as well as identify where to expend your energies.

Measure and monitor your traffic regularly to verify your model.

Use the model for long-range scenario planning. Understand how dramatically you will have to change your deployment to meet your overall growth projections for upcoming years.

In a production system, keep the error logging level to ERROR and not MESSAGE. The MESSAGE error level is verbose and can cause the file system to quickly run out of disk space. The ERROR level logs all error conditions and exceptions.

Run the perftune script on one of your production servers to know if the thread limits are being reached and if you need to further tune web server parameters.

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:

System architecture

Software installation and configuration

Operational procedures, also known as a “run book”

Software customizations

Custom code

Third-party products integration

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.



Tip	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.