Sharing the process of a project area

Edit online

Process sharing enables various project areas to share roles, permissions, operational behaviors, work item, and process configuration information. In process sharing, one project area holds the shared process, which can be used by any number of consuming projects. The shared process along with any process elements defined in the consuming project area, creates an effective process, which governs behavior in the consumer.

After you create a project area, you can make its process available to other project areas. By sharing a project area process, you can ensure that all project areas across your organization use the same process and also centralize process maintenance.

The following sections summarize the concepts related to process sharing:

Process templates

When you create a project area, you must specify a process template that will be used to define the initial process for the project area, even if you plan to have that project area use the process from another project area. After you create a project area, you can modify it so that it uses the process from another project area.
Note: For Change and Configuration Management and Quality Management project areas, you should use the unconfigured process template to create a project area that will consume process from another project area because that template does not configure any process on its own. Using a template that defines its own process causes the project area that consumes process to override the process it is consuming, which is not usually the behavior that you want.

Process inheritance

When a project area is created by using an existing process from another project area, it inherits only a specific set of elements from the shared process. Aspects such as roles, permissions, operation behaviors, and process configuration data are inherited in the sharing project area. However, some aspects of the shared process such as members, timelines, and iteration types are not inherited. You can customize the inherited elements, if the element is not marked Final in the shared process.

Note: The inherited settings are not shown in the project area editor of the consuming project area, but they are used at run time.
Elements that are inherited from the sharing process
  • Configuration data (applies to Change and Configuration Management and Quality Management only)
  • Work Item configuration metadata (for example: types, attributes, workflows, plan types, and so on)
  • Iteration types
  • Operation preconditions and follow-up actions (applies to Change and Configuration Management and Quality Management only)
  • Permissions
  • Roles
Elements that are not inherited from the sharing process
  • Administrators
  • Members and their role assignments
  • Process description
  • Project area artifacts, such as:
    • Work items
    • Plans
    • Plan views
    • Reports
    • Report folder structure
    • Test cases
    • Files under source control
  • Project area links
  • Releases
  • Timelines and iterations
  • Work item category associations (applies to Change and Configuration Management and Quality Management only)
Tip: It is a good practice to avoid using the sharing project area as a production project area. The sole purpose of the sharing project area must be to provide process for the consuming project areas. If you store production data, such as work items and plans, in the sharing project area, you might need to customize that project area in ways that make it difficult for consumer project areas to reuse the process.

Using the 'Final' flag to prevent customization of the process settings

By default, project areas, and child team areas that consume the process of another project area can customize process settings. However, as project administrator of the sharing project area, you can control which settings can be overridden in the consuming process, by setting the Final flag. If the configuration data of the provider project area is marked final, then that element is ignored in the consumer’s configuration data.

For example, if the Work Item Type Customization is set to final in the sharing project area, it is not possible to create custom work item types in the using project area. In the following image, the Save Work Item permission setting is selected and Final (ignore customization of this operation in child areas) is selected. In this example, project administrators of consuming project areas and team areas cannot restrict this role from performing Save Work Item operations. Although the project administrators can make changes in the editor of the consuming project area, the changes are ignored at run time.

This picture is a screen capture of the Permissions tab of the project area editor, which shows a checkbox for specifying that child project areas and team areas cannot override the permission setting of the selected action.

If the final flag is not set for a section, and you customize it in the consuming process, the customization in the consuming process overrides the shared process. It disrupts the process inheritance for that section in the process.

Configuration Data Delta

A configuration data delta allows for fine-grained customization of a section of configuration data. The common use case involves process sharing, such as if the administrator of a project area that consumes process from another project area wants to change a piece of configuration data without overriding all the related data that comes from the provider. For example, a consuming project might need to modify a work item type but does not want to override all the types defined in the provider. For more information, see Syntax for Configuration Data Delta.

Process configuration is managed as a group of process elements. For work items these process elements are as follows:
  • Types and Attributes
  • Enumerations
  • Attribute Customization
  • Workflows
  • Editor Presentations
  • Quick Information Presentation
  • Predefined Queries
  • Query Editor Presentations
  • Approval Tracking
  • Work Item Templates
  • Change Management Type Binding
  • Email Templates.

You might customize the consumer’s process configuration for any process element. But when you customize the process configuration for a process element on the consumer then the consumer uses its own process configuration for that entire process element. This happens for each process element in an all or nothing manner. Once you have customized a process element on the consumer, it no longer uses any settings for that process element from the provider. If the configuration data of the provider project area is marked final, then that element in the consumer’s configuration data is ignored. For more information, see Work Item Configuration and Shared Process in Rational Team Concert and Changing your work item process configuration – Best Practices.

Limitations of customizing configuration data

If you customize configuration data in a project area that consumes the process of another project area, all the configuration data for that category is copied from the sharing project area to the consumer project area, and the consumer project area no longer inherits any of the configuration data for that category. For example, the following figure shows the categories of work items configuration data in the IBM® Engineering Workflow Management client for Eclipse IDE. If you customize the Types and Attributes configuration data in the consumer project area, that consumer project area no longer inherits any of the Types and Attributes configuration data from the sharing project area. Unless you are certain that you do not want to inherit any of the data for a configuration data category, do not make any changes to that category of configuration data in the consuming project area.

Screen capture of the Configuration Data section of the project area Process Configuration tab in the Engineering Workflow Management client for Eclipse IDE. The Work Items node is expanded, and the Types and Attributes category is selected.
Note: If you add a custom work item attribute to the sharing project area, you must update existing work items so that they contain the new custom attribute. Also update work items in the consuming project area. For details, see Updating work items with new or modified attributes.

Changing and upgrading the process

A key benefit of using a shared project area is that changes that you make to the process of the sharing project area immediately apply to the project areas and team areas that consume that process. You can change the process for all project areas by configuring the process in the sharing project area. In addition, when a new version of the process template that the sharing project area uses becomes available, you need only update the sharing project area with the new template. In this way, you can control the upgrade of all project areas across your organization from one sharing project area. Consuming project areas and team areas that have customized some process settings retain those customized settings. For more information, see Best practices of process sharing.

Restrictions

The following restrictions apply when using shared project areas:

  • Project areas that share their processes cannot configure process for iterations because iterations are not shared.
  • If you configure process for a project area’s timelines or iterations, you cannot make that project area’s process shareable.
  • Project areas that share their process must be visible to all members of the consuming project areas. Therefore, if you restrict read access to the sharing project area, members of the consuming project area can still access the sharing project area.
  • You can modify a project area that consumes shared process from another project area so that it consumes shared process from a different project area. However, you cannot modify that project area so that it uses a template instead of a process for a shared project area.
  • A project area can share its process or can consume the process of another project area, but it cannot do both.