Blueworks Live has a built-in mechanism that makes it easy for the process creator to have their work approved and published within a simple space structure. They can work on revisions to a model without affecting the published version. In some organisations this mechanism does not provide enough separation of concerns between the creator/editor, the reviewers, and space administrators. For these situations, an alternative is suggested in this blog post.
Blueworks Live provides “out of the box” facilities to manage the lifecycle of Process Blueprints and Decision Models.
This diagram shows the lifecycle for a Blueprint.
The Blueprint editor is responsible for creating a snapshot version of the Blueprint that can be published. Typically this snapshot will be approved by another editor or contributor using a Blueworks Live Process Application.
If approved, an Editor will click the publish icon on the Blueprint snapshot to make it available to viewers and to mark it as the “live” version of the Blueprint. Editors are then free to work on future versions of the Blueprint with the knowledge that the published version is the one that will be seen by viewers.
Any communication between the reviewer and the creator/editor can be managed using comments in the Blueprint and via Blueworks Live's collaboration tools.
This procedure is simple and well supported by the tool.
Some organisations find that this standard approach does not allow for a “separation of concerns” between the Blueprint creator and the published version. The editor can make changes to the model and re-publish it at any time.
If an Enterprise wants to have a more governed approach to publishing Blueworks Live models. There may be a need for a separation of concerns between the Blueprint creator/developer, the reviewers and the published version of the Blueprint.
This model shows one way in which this can be accomplished.
A space structure with Development, Staging and Published spaces is required.
The Blueprint Creator/Editor creates a snapshot of the Blueprint and then copies it to a staging space. They then start a Blueworks Live Process Application to get the Blueprint approved and published.
Reviewers can only work in the staging space(s).
If the reviewer(s) are not happy with the Blueprint they can cancel the Review Process Application and comment in the application. This will be seen by the Blueprint creator. Any comments added to the staging version of the Blueprint will be available to the creator but will not appear in the development version of the Blueprint. At this point the Administrator or Curator will be prompted to archive the staging Blueprint.
If the Blueprint is approved the Process Application will prompt the Administrator or Published Space Curator to copy the Blueprint into the Published space and to archive the staging version.
This copy will then be published and made available to viewers.
The creator/editor can continue to work on refining or updating the development version of the Blueprint.
Pros for this approach:
- Clear separation of concerns
- Control of published Blueprints
Cons for this approach:
- Requires administrative effort
- Does not exploit collaboration features built into BWL
- More Complex
This blog post is based on a client project performed by Gerry Baird and Mark Ketteman, IBM Business Automation UK and Ireland.