Many business processes are ways of managing the life cycle of items of business information. For example a Fulfil Sales Order process could be the way of managing a Sales Order from creation through various steps to its fulfilment.
You may even consider that the business information entities, their allowed states and the business events that can cause transitions to other states, are more fundamental and stable than business processes, which are relatively arbitrary business-level solutions designed to enact the information life cycles.
There is really nothing new in here, just modern notation and ‘service’ talk. Who else remembers Event Partitioning or Entity Life Cycle Analysis?
If life cycles sound like a useful approach, a business state machine is a complementary technique for modelling the state- and event-based business behaviour. A business state machine can define the reaction that should occur (in the business or in a process automation orchestration) for each state a Sales Order (for example) can be in when each type of business event occurs.
For business analysis of the state- and event-based rules that constrain the sequence of activities, a business state machine can optionally complement a BPMN process diagram. It can be used to verify the integrity of the process diagram with regard to business entity life cycle rules:
- conformance – the process does not break the life cycle rules by performing illegal state transitions.
- coverage – the process covers all the states and transitions.
For example, IBM recommends (with caveats) that business state machines are useful for modelling processes that involve in-flight modifications or cancellations (e.g. to Sales Orders - modifications or cancellations are events that can occur at any point in the order’s lifecycle), and timeouts. Modelling these event-at-any-point situations with process flow diagrams would result in a mesh of sequence flows that would be easy to get wrong.
[Business State Machine is an IBM term, from WebSphere Process Server].
Whether they are defined through business analysis or not, business events, states and transitions are particularly important to architects designing services in a business-focussed SOA, because:
- A service contract includes a set of messages exchanged to communicate the business events; the meaning and form of the messages must be agreed between service consumer and provider.
- The exchange of messages must occur in certain patterns, i.e. a business protocol (a ‘choreography’ in BPMN).
- The production and consumption of messages by any participant’s activities is governed by the participant’s state- and event-based rules, organised into an orchestration.
- Orchestrations explicitly manage state information.
"It is the resource lifecycle events that are important when trying to identify the services that your business process will depend on. The business events advance the business data through a state machine until the end of the business process. ... it is the business events and their message and data (documents) that are the key artefacts in your modeling efforts when creating a service-oriented architecture."
"Semantically, a Web Service is just a ... state transition request on a target resource.... semantic equivalence can always be found between Web Services operations, an event, an action and a state transition of a resource, provided that the resource is clearly identified."Various Business Process Management tools can use the state machine paradigm:
- IBM WebSphere Process Server: business state machine
- MetaStorm Designer: stages & actions
- Vitria BusinessWare: state model
Example – Sales Order
Diagram 1: Sales Order entity - Allowed states and transitionsUML State Machine Diagram
(click diagram to view)
The diagram above shows the fundamental life cycle of a Sales Order, regardless of any business process that might be put in place to achieve it.The next diagram shows a possible choice of business behaviour that conforms to these life cycle rules and covers the full life cycle. The business behaviour is in the form of actions performed on transitions between states or activities performed when entering or exiting a state.
It has been annotated as follows, to identify equivalent elements appearing in this diagram and the next one:
M: message flow in BPMN (incoming ones) = event in state machine
S: state in state machine = implicit in some start/end events in BPMN, or no explicit model element
T: transition in state machine = implicit transition in BPMN (no explicit model element)
A: action or activity in state machine = task in BPMN
Diagram 2: Sales Order entity - With actions and activities
(click diagram to view)
This sequence of actions and activites is shown in the familiar process flow view in the following diagram. Note the equivalence to Diagram 2.
Diagram 3: A Task Flow that would achieve the Life Cycle
BPMN Process Diagram
(click diagram to view)
Posts
