# Deployment Planning

# Planning Portal Structure and Content

This chapter describes portal structure and content at a high level.

The purpose of this chapter is to assist in planning portal structure and assigning administrative responsibility for managing portal content.

This chapter contains the following sections:

- Single Portals and Federated Portals
- Experience Definitions
- Communities
- Portlets
- AquaLogic Interaction Search

## Single Portals and Federated Portals

It is possible to deploy a single portal or multiple, federated portals. Figure 2-1 illustrates a single portal deployment where different experience definitions provide a portal experience specific to each group of users. Figure 2-2 illustrates federated portals, where instead of experience definitions on a single portal, each federated portal provides a different portal experience.

Figure 2-1 Single Portal with Multiple Experience Definitions

Figure 2-2 Federated Portals

Having a single portal with one or more experience definitions has benefits over deploying multiple federated portals. In a single portal deployment:

- Users have different experiences but are managed in a single place.
- The AquaLogic User Interaction deployment is easy to scale. IT needs only to look at total use for a single set of hardware versus fragmented use for multiple sets of hardware.
- It is easy to distribute enterprise-wide communications.
- It is easy to integrate enterprise-wide business processes.
- There is a common content management system

## Experience Definitions

Experience definitions allow you to present different audiences with different branding and features in the portal.

For example, you could create an experience definition for a particular customer. The experience definition would include the customer’s logo and company colors and include access to communities and knowledge directory folders specific to the needs of the customer.

Experience definitions are applied according to rules configured with the Experience Rules Manager.

For information on configuring experience definitions and rules, see the section Configuring Experience Definitions in the Administrator Guide for AquaLogic Interaction.

## Communities

Communities are pages shared between members of a group to facilitate collaboration and communication on a particular project or on departmental goals.

Communities provide the following benefits:

- A consistent user experience for members of a department or project group.
- Discussion forums in which community-pertinent information is discussed and archived.
- A version-controlled repository for project or departmental documentation.

For details on implementing communties, see the documentation for AquaLogic Interaction Collaboration.

The following are potential use cases for communities:

- Business Unit Resource Center (Line of Business Communties)
- Interactive Workspace (Collaborative Communities)
- Customer or Partner Management Site (Sales and Service-Oriented Communities)
- Dashboards (Analytic Communities)
- Business Process Applications (Process Communities)

### Business Unit Resource Center (Line of Business Communties)

Audience | Business unit or department Customers of that business unit or department
Content | Community documents, links, calendar Metrics Expert finder Q&A
Success indicators | Strong departmental or group identity Existing intranet as content source Motivated community owner
Pitfalls to avoid | Static page that people visit and forget
Suggested AquaLogic Interaction tools | Portlet Framework - Microsoft Excel Publisher

###

### Interactive Workspace (Collaborative Communities)

Audience | Ad hoc or established project workgroups
Content | Project task list Document management and archive Project calendar Threaded discussions Project metrics
Success indicators | Members spread out Project has specific objectives and milestones Project has outgrown e-mail and file-shares
Pitfalls to avoid | Dustbin of history: old projects, communities that do not go away Ghost town: two or three people are probably not enough
Suggested AquaLogic Interaction tools | Collaboration Studio Portlet Framework - Microsoft Excel

###

### Customer or Partner Management Site (Sales and Service-Oriented Communities)

Audience | Customers or partners
Content | Key customer or partner resources: documents, calendar Self-service access to CRM or PRM system Feedback mechanism Customer-to-customer or partner-to-partner: facilitate community
Success indicators | Portal-only access for critical information Responsiveness to customer/partner feedback
Pitfalls to avoid | No human input
Suggested AquaLogic Interaction tools | Collaboration Studio Portlet Framework - Microsoft Excel

###

### Dashboards (Analytic Communities)

Audience | Management
Content | Performance metrics Financial documents
Success indicators | Support to enforce consistent data formatting Portal-only access for critical information Culture of accountability based on metrics
Pitfalls to avoid | Make sure the dashboards have fresh data Make sure security works appropriately
Suggested AquaLogic Interaction tools | Portlet Framework - Microsoft Excel Integration Services for SAP and PeopleSoft

###

### Business Process Applications (Process Communities)

Audience | Users involved in process
Content | Published content Data from multiple systems Workflow Metrics
Success indicators | Simple navigation, consistent branding a priority Unified search criteria Looking to utilize reusable components, common foundation
Pitfalls to avoid | If you do not have a process, the software will not do it for you
Suggested AquaLogic Interaction tools | Publisher Collaboration Process Search Studio Portlet Framework - Microsoft Excel

###

## Portlets

Portlets are applications embedded in a portal and can be interactive or solely informational. They are able to communicate preferences with the portal and to communicate with other portlets.

A portlet must be based on a web service. The web service controls the bulk of the portlet settings, such as the URL and cache settings. The portlet definition in the portal contains the name, width, type, and administrative preferences, if any.

Portlet templates allow multiple instances of the same portlet to be created, with each instance potentially different in appearance or information.

AquaLogic User Interaction includes pre-made portlets and the ability to easily create portlets using products such as Studio and Publisher.

Portlets can also be developed from scratch using the AquaLogic Interaction Development Kit (IDK). For details on portlet development, see Developing Portlets in the Developer Documentation.

## AquaLogic Interaction Search

AquaLogic Interaction Search allows users to quickly and efficiently find a wide variety of information from sources across the enterprise, both inside and outside the AquaLogic User Interaction products. Search can be distributed across a multiple server cluster.

### Searchable Content

There are a number of possible sources of searchable content, and it is important to understand the options for providing that content to end-users:

- Knowledge Directory: The core of the AquaLogic User Interaction knowledge management infrastructure is the Knowledge Directory—a hierarchy of folders that contain links to files of various formats, stored in different types of repositories. Files can be crawled into the Knowledge Directory or manually submitted and can be filtered into the folder hierarchy (also known as a taxonomy) in order to provide an entry point to high-quality, organized content. In addition to the out-of-the-box functionality, virtually any repository can be made searchable through the creation of Content Services. All items in the Knowledge Directory can be searchable.
- Collaboration: The project workspaces provided by Collaboration contain documents, threaded discussions, announcements, and task lists contributed and managed by distributed teams. All items in Collaboration can be searchable.
- Publisher: The form-based data entry and file management provided by Publisher allows specialized content submitted by users to be published and surfaced in the portal through portlets. All published content items associated with portlets can be searchable.
- Portal Administrative Objects: Users, web services, portlets, Content Services—all the objects that make up the administrative infrastructure of a portal are searchable. End-users can search for users (to view profile and expertise information), communities (to visit or join), and portlets (to add to a My Page). Administrators (who need to create and manipulate all types of objects) can search for a wider variety of items and have more advanced options in their search results.
- Non-portal Searchable Content: Legacy search engines and repositories with pre-existing search or query functionality can often contain valuable sources of content that for various reasons cannot be crawled into the portal or managed through Collaboration or Publisher. With search web services, any repository that can respond to queries can be extended with a web services adapter so that it can be searched from the portal. Results from a number of disparate search providers (both inside the enterprise and on the internet) can be aggregated in this way.

The Search administrator is responsible for creating and scheduling the initial search index jobs as well as update jobs. The Search administrator is also responsible for customizing search “Best Bets” and the search thesaurus.

### Grid Search

Grid Search refers to distributing AquaLogic Interaction Search nodes over multiple servers. Search servers can be configured to be stand-alone or a node in a search cluster. In a search cluster, the search index is divided, or partitioned, across multiple search nodes.

You can manage the search cluster using the Search Cluster Manager or the command line utility cadmin.

For more information on administering Grid Search, see Managing Grid Search in the Administrator Guide for AquaLogic Interaction.

#### Grid Search Best Practices

1. Do not deploy multiple nodes on a single host in a production environment.
2. Schedule checkpoints when there is little or no planned indexing activity. This will help ensure that the checkpoint reflects the most up to date information and minimize recovery time.
3. Set the Search Cluster Manager Service to manual or disabled on all but one server. Only one instance of this service can be utilized by the portal.
4. A single search sever can be installed as a search cluster with one node, rather than a stand-alone search deployment. This helps streamline the process of adding future search nodes.
5. In a multiple node deployment, configure the cluster home directory on a server other than the search servers themselves. If the cluster home is located on one of the search servers, that server is a single point of failure for the entire cluster.
6. Cluster home should be located on a high-availablity file system with fast connectivity to the search node host machines. Ideally, the cluster home should be on a RAID file system to ensure availablity and falut tolerance.
7. Search nodes should be located within the same subnet on the network, and ideally on the same switch.