Best practices: Setting up spaces and workspaces
This topic provides best practices and recommendations for setting up spaces and workspaces in ALM Octane.
This overview provides basic information about the various types of spaces in ALM Octane and how to work with them.
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.
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.
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,
Types of spaces
ALM Octane Enterprise edition provides the following types of spaces: Shared and Isolated.
|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.|
(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.
This topic provides strategies for planning spaces (both isolated and shared) in your ALM Octane deployment.
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.
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, integration among the applications, and so on.
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.
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, lists, and so on.
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.
Note: Managing common customization for large number of workspaces might result in a very complicated customization at the shared space level that is hard to manage and eventually can also cause performance degradation. If the shared space admin does want to have a significant portion of the customization shared, the more workspaces there are with greater variance, the more work the shared space admin needs to do to manage the variance.
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.
Note: Same applies also to management of shared assets. If there are too many variations between the workspaces and the need for different shared entities, it results in a large number of shared assets which are hard to manage.
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,
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).
Note: For the purposes of this discussion, we will use the Oracle terminology.
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.
This topic provides strategies for planning workspaces in your ALM Octane deployment.
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 partition data within a workspace.
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 Set up data access.
Consider the following factors.
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.
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.
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.
Try to break down your spaces into as many workspaces as possible as this helps ALM Octane perform better and makes searching for data, and concentrating on your tasks, easier. The best practice is to have many small workspaces in the same space instead of a few, very big workspaces.