Stages 7.6 brings innovative new capabilities that speed up the whole lifecycle from modeling over reviewing and approving new processes to their practical execution in the context of a project or program.

Other new features accelerate the modeling of large process landscapes and assuring compliance to standards and regulations.

The new process release capability can automate review, approval, and update steps. Different automations can be defined, e.g. for review and approval of a process version or to approve and release a process tailoring for a project.

Possible automations include:

• Creation of process versions
• Notification of stakeholders via email
• User interactions, e.g. for reviews and approvals
• Propagate version states, e.g. from “ready to review” to “released”
• Release processes as valid and push updates to other workspaces
• Reminders and timeouts
• Permission assignment

Any user can participate in a review or approval step.

A sample automation for a process review followed by an approval could look like this:

If you need help to adjust the automation to your needs or create new ones, please see here or contact your Stages product consultant.

Typical process management roles like process owners, modelers, reviewers, or approvers can now be directly defined as participants for each workspace.

By assigning a user as a participant, the user can automatically receive all necessary permissions to carry out the required duties. For example, a process modeler can automatically receive permissions to modify the processes and create new versions in that specific workspace, but not others. This minimizes the administration overhead and makes it easy to implement a well-structured process management governance.

All users can see who reviewed and approved a process, even in complex process landscapes using multiple layers of process modules.

See here and here for more info.

To assure that processes are actually applied in practice, the defined process activities need to be planned, executed and monitored. The latter typically happens in task management tools (also known as Application Lifecycle Management or ALM) like Atlassian Jira or IBM Engineering Workflow Management (formerly known as Rational Team Concert or RTC).

With Stages version 7.6, modelers can extend the processes that should be executed with the new “activator” elements and deploy the resulting executable models directly into those task management tools.

In contrast to BPMN and similar modeling techniques, the business process logic can be separated from the technical task execution and platform details. With the Stages approach, the same process can be executed in Jira in one project and IBM Engineering Workflow Management in a different project, each with its individual tailoring. Both processes can be derived from the same organizational standard process, which assures compliance with all required standards and reference models.

Stages comes with different predefined activator types. The “Step-by-step” activator executes all activities in a workflow sequentially as defined by the predecessor/successor relationships. The “All-at-once” activator creates all tasks of a workflow in one step. Users with the respective permissions can start those process executions directly from Stages. Alternatively, they can also be triggered by an action in the task management system. The technical execution can also be scripted for maximum flexibility.

See here for more info. If you need help to exploit the full power of the new process execution capabilities, please contact your Stages product consultant.

To manage complex engineering process landscapes, they need to have a clear architecture of different functions, disciplines, or process areas with well-defined interfaces to each other.

The new workspace collections can group workspaces so that process interfaces are automatically proposed to the process authors during modelling.

For example, while defining a software test process, Stages can automatically propose interfaces to software requirements, software design and implementation, or software project management. This avoids duplications and other potential inconsistencies and greatly speeds up modeling of large process landscapes.

Collections can also be used to optimize the Stages search experience.

See here for more info on workspace collections.

Compliance mappings to reference models and standards is normally started via Management > Compliance. With Stages 7.6, elements can be directly mapped to reference models from the Compliance perspective without leaving the process context.

See here for more info on how to do this.

When importing a process module into a workspace, the modeler can now choose if future updates of the imported module should be pushable into the Working Version. 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 workspaces, use the … > Update menu.

When importing modules that have interfaces with each other, the import of the first module always causes warnings because of missing interfaces. With the new refresh update, the modules with warnings can be updated to the same version again. This should resolve all interfaces and result in a warning-free process landscape.

See here for more info on how to push modules.

The default table style in the description editor has been updated to include borders for more clarity and easier process understanding.

A banner can be configured to inform users of sensitive environments about restrictions, access indicators, or export notices.

Project-scope attributes will be imported and updated with process modules, if config property import.project.attributes.from.modules is set to “true”.

Encrypted SAML Assertions are now supported for Single Sign On.

Normally Stages is started by the “root” user and then drops its privileges to the “stages” user after successful startup. In high risk environments, Stages can now also be started with a user id other than root. It can be enabled via the STAGES_NONROOTSTART variable in …/bin/rc.conf. If enabled, the same user id starting the service will also be used to run the service.

Please note that privileged ports below 1024 cannot be opened in this configuration, so the normal HTTPS port 443 cannot be used. The non-root setting can only be used when the Tomcat connectors are configured to use ports higher than 1024 and e.g. a reverse proxy is being used to allow normal access via HTTPS.

The following actions are necessary if you are upgrading from version 7.5 to 7.6:

• The CMS cache folder …/stages/data-cache/cms-cache needs to be deleted. It will be automatically recreated after the restart.

For topics marked with *: please contact your product consultant for more info on how to integrate those enhancements into your configuration.