3 Dimensional State Pattern
State Handling for Active Service, Configuration and Product Management
States and State Models are essential to Configuration and Service Management and indirectly also to Product Management, that relays in part on the same data basis.
The states define visibility in CMDBs, Assets are managed based on the states and so on. There are many reasons why you should invest into clear status models.
There are principles out there on how to define a state model or a state machine. But what most people overlook is that there are three different dimensions of state models you have to take care of, if you are working towards a completely integrated environment of tools in the enterprise business. And of course with more dimensions the complexity in the single dimension gets lower.
For example if you only have to think about your workflow state (like In Progress) but not of the state of the object itself (e.g. Running or Not Running) your model gets easier.
The Three Dimensions
Lifecycle State
Trigger Points and process results for your orchestration and workflow systems. These states concern the workflow rather than the object itself. This state decibes what is done with the object. They depend on your specific environment and on how you want to get things done.
Operational State
This is the only State dimension related and bound to the object itself and describes the status of itself. Is it up and running, is it down, is it in idle?
This state is cross- and multi-phase and it is consistent in every tool involved.
It describes for example wether the object is working or not, wether it is set up or still on stock. The same object realized by different workflows and in different lifecycle states may have the same operational state.
Tool State
The tool state is related to the object but it describes states needed for a specific tool to work. So for example the visibility of the object to user groups, the business logics, steerings and behaviours of the software system are constrained by the tool state. If for example an object is released, the system may prevent changes you make to it. These states are fixed to match the requirements of standardized software.
An Example of a reduced State Model
In interplay with the status definition the coupling in between can be defined. States can trigger each other between the models.
If you would try to get them together into one Model, you would have to multiply out some of the states, it would be less clear and the models complexity would increase.
But why?
If you’re not shure if it’s worth the effort, think about some situations you might benefit from this pattern:
- Transparency if you have to communicate requirements to your team or if your team is communicating to you.
- Confirmability in the tool you develop.
- If you need something you have to relate your Business Logic and functionality to.
- If you design Workflows.
Phase vs State: An important Principle
A Phase is not a state. In one Workflow-oriented Phase the object you talk about can have different states for example or the state could stay even after finishing.
