Best practices for setting up spaces and workspaces

This topic provides best practices and recommendations for setting up spaces and workspaces in ALM Octane.

In this topic:

• Overview
• Planning how to set up spaces
• Planning how to set up workspaces

Overview

This overview provides basic information about the various types of spaces in ALM Octane and how to work with them.

Terms

Site	Top level container. Allows the management of the different spaces created in ALM Octane as well as a place to carry administrative tasks and manage users.
Space	Top level logical container. Provides absolute isolation of data. A space is the highest container level that allows data sharing and interaction. A space allocates its own resources when created, such as relational database schema, Elasticsearch indexes, and the repository location.
Workspace	A working container. A user always works in the context of a specific workspace. A workspace is always contained in a shared space and provides logical isolation of data and settings. The level of isolation is defined by the type of shared space created.

For details about the site and spaces, see Manage spaces (for space admins).

Types of spaces

ALM Octane Enterprise edition provides the following types of spaces: Shared and Isolated.

Shared space (Enterprise edition)	Workspaces share customization and can share data. Cross workspace reporting is possible. Some entities may be defined as global and be viewed across all workspaces.
Isolated space (Pro and Enterprise editions)	Each workspace defines its own customization. No sharing between workspaces. A user can be assigned to multiple workspaces and seamlessly switch between them. Note: Pro edition only allows creation of isolated spaces. Shared spaces are an enterprise level feature.

Back to top

Planning how to set up spaces

This topic provides strategies for planning spaces (both isolated and shared) in your ALM Octane deployment.

Space strategy overview

When planning your ALM Octane deployment, it is important to plan how to break down your projects into a structure that provides you with the best experience for your teams.

Generally, unless there is an actual need for complete isolation of workspaces, use shared spaces(instead of isolated spaces). The use of shared spaces allows you to better scale out ALM Octane as your projects grow.

Consider the following factors.

Amount of interaction and data-sharing between projects

If you have projects that have close interaction and work together frequently, consider putting them either in the same workspace or in different workspaces under the same shared space.

This best practice is relevant in both this use case, sharing data, and also the use case for having similar processes and shared customization. For more suggestions about working with similar process and shared customization, see Projects that have shared processes and policy.

When trying to evaluate and understand interaction level between the projects, and the need to share data, relate to factors such as team collaboration level, dependencies among teams, common releases, and integration among the applications.

The level of interaction between teams is the most major factor for deciding whether teams and products should be in the same workspace. For details, see Planning how to set up spaces.

If you define teams and products in separate workspaces, knowing that the teams and products need some level of interaction that require dependencies between entities and sharing of data, these workspaces should reside within the same shared space. Workspaces that reside within the same shared space are able to more easily share entities and set dependencies between entities in the following ways:

• Define shared entities at the shared space level.

• Move entities from one workspace to another.

• Define dependencies between entities on different workspaces within the same shared space.

Projects that have shared processes and policy

If you are an enterprise customer, you can enforce your process and align organizational standards to all workspaces within a shared space by customizing at the shared space level. This customization is achieved using business rules, common fields, workflow, and lists.

ALM Octane also provides customization on the workspace level, so the teams and products don’t have to be fully aligned. However, defining the main processes and standards at the shared space level is advantageous because not only does it apply to all workspaces, you can also add additional processes, definitions, and standards for specific projects in specific workspaces. This provides flexibility.

If you have sets of workspaces that do not need any interaction, the recommendation is to separate the sets of workspaces into different shared spaces, and manage the common customizations on the different shared spaces accordingly.

Make sure that the customization at the shared space level is relevant and needed for all workspaces. Additional flexibility can be done at the customization of each workspace, but if there is a need for common customization for partial set of workspaces within the same shared space, then probably these workspaces should be in a different shared space.

Cross-workspace reporting

If there is a need to track projects managed in different workspaces, having these workspaces on the same shared space enables cross-workspace reporting, which reflects the data from different workspaces in the ALM Octane dashboard. For example, if two projects share the same release and you want to understand the progress of each project in the release, put each project in its own workspace, and make sure both workspaces are under the same shared space,

Cross-workspace reporting is also possible even if the workspaces are under different shared spaces. You can do this by using OData, which extract workspaces data to external BI tools. For details, see OData support for extended reporting.

Data isolation

If a project requires absolute data isolation, define the project in a workspace in its own isolated space. This ensures that there is no way to inadvertently expose confidential information between projects.

Disaster recovery planning (DRP)

Each space is stored in a different database schema (Oracle) or database (SQL Server).

Workspaces within the same space share the same database schema as the space. This means that backup and recovery can be done over an entire space, and it includes all its workspaces.

Recovery therefore recovers all workspaces in a space. You cannot recover just one workspace in a space.

Back to top

Planning how to set up workspaces

This topic provides strategies for planning workspaces in your ALM Octane deployment.

Workpace strategy overview

Similar to the strategy for setting up spaces, consider how to partition projects within a space. The factors to consider are similar to the space strategy parameters, but on a smaller scale.

If the projects are tightly intertwined, and a large portion of the data needs to be used by different teams in these projects, the projects should reside within the same workspace to allow ease of sharing of data.

You can make sure that each project member only sees the information that is relevant in the following ways: 

• Use basic filtering to view subsets of data within a workspace. For example, you can filter by program.

• Assign and customize roles. For details, see Assign roles and permissions.

• Customize module access. For details, see Module Visibility.

• Set up data access. For details, see Data access (Enterprise Edition).

Consider the following factors.

Sharing of data between teams

The main factor for deciding whether teams and projects should be in the same workspace or separate workspaces is the level of shared data that is common for the teams. If teams share the same release planning and content, or have strong dependencies on different entities, these teams and projects should probably share the same workspace.

Data isolation

Different workspaces provide data isolation. If there is a need to isolate data between the different teams and projects, this probably indicates that these teams and projects should be managed in different workspaces.

ALM Octane provides data access capabilities, but these should be used for specific cases when some entities need to be hidden for certain users and teams, and not in the case of most data needing to be hidden. If most data needs to be hidden between teams, use different workspaces.

Different processes

All workspaces within the same shared space inherit the common customization from the shared space level.

You can customize each workspace even further, on top of the shared customization for the space. This enables you to define additional processes relevant for the workspace level only. If there is a need for different customization at the workspace level for compliance with different processes, and there is no need to share data, we recommend that you define these projects and teams in different workspaces.

Back to top

See also:

• Best practices