Define a Process Architecture

The Process Architecture is the hierarchal design of the processes. As the business undergoes changes and processes become more complex, a strong process architecture ensures that processes remain in their optimal state. Organizational strategy, structure, process ownership, and program portfolio are some of the key considerations that go into defining the architecture.

In Stages, since each of the processes resides in its own workspace, process architecture is represented by the hierarchy of the workspaces. Before integrating it into the next process in the hierarchy, it is recommended that each process should be baselined (versioned) and only the valid version of the process should be integrated.

Above is an example of process architecture. Since common elements like phases & milestones, common roles (e.g. stakeholders) are defined at the corporate level, they have been defined in a workspace called ‘Common Elements’. This workspace is then integrated into each Process Area workspace.

Furthermore, all the process areas are integrated into a single Standard Process workspace called ‘Software Engineering’ which contains all their process elements (workflows, activities, roles, phases & milestones, work products, and guidance).

In the final layer, specific programs have been instantiated from the ‘Software Engineering’ workspace. This is done by first integrating the ‘Software Engineering’ process into the Program workspaces and later tailoring each of the Programs.

Below we see how the Process Areas defined in the above example would show as workspaces in Stages.

Integrate Processes

In order to integrate a process into the next level, use the option Add module on the Process start page. In our example, once the Software Engineering workspace is created, all the process areas are added at one go by using the Add module option. The recommended practice is to select the valid version of the processes to be added.

For any existing workspace, more modules can be added by navigating to Management>Process Modules and clicking or tapping on Add Module.

Update an Integrated Process

Once a valid version of a process module has been released, the processes where it is integrated needs to be manually updated to consume the valid version.

Navigate to Management > Process Modules of the integrated workspace and select Update. Once the valid version is updated, the circular orange icon changes to green with a ‘V’ in it.

Multiple modules can be updated within one action by using the menu in the top right and then selecting Update.

A module can also be removed from an integrated process by selecting the Remove operation. This will remove the inherited process elements of the selected module from the integrated process workspace.

Update several Modules via Push

The update also works in the other direction. If a module was integrated and “Push Updates” has been enabled for it either during the integration or later on in the module's properties, a module update can also be pushed from the source to the target.

To push a process module into all workspaces that have the module imported and push-update enabled, go to Management > Process Modules and select the Usage tab. Then select the version to be pushed and click or tap on the Update icon. To select multiple modules at once, use the … > Update menu and check the respective selection boxes.

Interpret Update Warnings and Refresh Versions

In some cases, module updates show certain warnings. There are two typical causes for those:

1. Changes to the process metamodel.

If types, associations, or attributes have been renamed or deleted in the metamodel, the respective data might still be present in the database. In case of an update, a warning is being created. Those can typically be ignored.

2. Interfaces between modules

If two modules are integrated that have interfaces between each other, the integration of the first module will cause warnings, because the targets of the interfaces could not be found. As soon as the second module is integrated, the interfaces will be correctly created.

Nevertheless, the warnings from the first module intergration will still be shown.

The solution is to update the first module to the same version again:

If the interface is still present in the second module, the warnings will go away.