Maturity system
This part of the documentation will go through the concept and usage of maturity systems.
Concept
SoftTypes defined for managed objects in ShareAspace can be configured to have a set of possible states (e.g "In Work", "Under Review", "Released" etc.). ShareAspace will keep track of what state an object currently holds as well as the history on what states an object has had. The history will track who set the object in a certain state as well as the time at which the state was set. In order for ShareAspace to handle the rules and business logic concerning states, ShareAspace comes with a Maturity System component. In the Maturity System it is possible to structure the logical order of different states as well as the rules that the object must fulfill in order to move to the next possible state. The Maturity System and its rules are defined in the SoftType configuration.
In the figure above a Maturity System has been defined for an object with three possible states,
InWork, UnderReview, and Released. The Maturity System is also defining the allowed transitions
that can be performed between the different states. When the object is InWork the only possible next
state is UnderReview. When the object is in the UnderReview state it has two possible transitions,
either back to InWork or forward to Released. Each state always has a default next state defined.
This is to allow for the possibility to have a "default" route for the object to navigate
from a start state to an end state in case the maturity system is setup with multiple branches.
Note
More than one Maturity System can be defined for a given SoftType.
Note
For definitional objects (Item, ItemVersion, ItemVersionDefinition), the state is always managed on the ItemVersionDefinition. For a Maturity System defined to record a release process this means that ShareAspace will always "Release" definitions, not versions.
Rules
When defining a Maturity System on a SoftType there are some different concepts to consider:
Entry criteria
The Entry Criteria of a State in a Maturity System is used to describe what conditions must be met for a SoftType to be assigned that state. The criteria or rules are described within the data section of a SoftType. Each defined state can have its own set of rules. As an example one entry criteria of a state could be that a certain attribute defined in the SoftType must have a certain value. For more advanced entry criteria it is possible to use one of the out of the box business logic components analyzing the data. It is also possible to write custom business logic components and refer to these in the Soft Type configuration.
Next steps
Each State in the Maturity System defines a set of possible next states. One state can be defined to be the default next step.
Entry approval
For each State, it is possible to define a collection of possible Entry Approvals that are qualified to approve the fact that an object will be in that State. An Entry Approval could be a Participant and its Role or just a Role.
When a SoftType fulfills the Entry Criteria of a "Next State" it is possible for a user who matches the Entry Approval to request a transition.
If multiple Entry Approval have been defined for the next State, the user will be able to select one User from the list of possible Participants and Roles or just Roles to approve the transition. When the request is sent a Work Item is created for the chosen Approver - asking this user to approve or reject the transition.
External entry approval
It is possible for the Maturity System to be configured to use an external service for validating whether to allow the entry to a state or not. The Maturity System will send a GET request to the configured service. The service must respond with a Boolean value (i.e. OK to enter state or not).
Freezing
It is possible to combine the states with the freezing mechanism in ShareAspace. Freezing is applied to definitions for Master-Version-Definition (MVD) objects and applied straight to the master object for non MVD objects.
The freezing states in ShareAspace are:
- Not Set - no freezing rule is applied
- SemiFrozen - possible to change Maturity State, all other characteristics contained on the Master (for non MVD objects) or Definition (for MVD objects) are locked
- Frozen - not possible to change Maturity State, all characteristics contained are locked.
When entering a Maturity System state with freezing defined that freezing is applied to the concerned object.