What to model – II

.
Now that we have a first idea of what our model of Business Process should be like.

However, what is it supposed to look like?

Well, as in any language, there are several levels of analysis: lexical, syntactic, semantic and pragmatic. Whereas the first two or even three depend on the language, the pragmatics define what you should obtain in real life.

Surprisingly, lots of information exist on those three first levels of language analysis. I mean “surprising” because they are just a means to obtain what you really want. This means that the modeler is given all this:

• rules about what he can or cannot express @ each level
• many shorthand & tips & tricks about how to translate from one level to the next
• rules of governance, because this gets really complex

This does not only overwhelm and give headaches to modelers, but the design space explodes because of the dimensions growth is exponential.
This is natural in approaches where the modeler should create a number of models that go from a very abstract one to –finally– one that is really executable, and those are written using different languages.

Since Intalio is not like other modeling tools, you can create your model and make it executable after very few changes. It is power at your fingertips.

I will start from the other end, the pragmatics, as a more natural way to constrain the business process design.

Actually, I will deal in this entry with what we should avoid (the design space outer space), in order to establish what we want to get (the actual target: BPM pragmatics).

THE BASIC THINGS TO MODEL
As I showed in a previous entry, a process model in Intalio is a description of what you actually do, in the form of tasks
Some features of that description are the following:

• Each task can be either composite (made up of other tasks) or not
• These tasks are performed by one or more actors
• The actors that fulfill the tasks are modeled via pools.
• The actors can be either organizational units, roles, real people, IT systems, or some unknown system.
• The most fundamental thing is that the functional/non-functional contract linked to each task is performed by some actor

Once we have understood what tasks and actors are about, we should start thinking of how to make them work together. This is done via communication:

• The underlying modeling principle is to make actors communicate in a proper, flexible, scalable manner.
• The model of sequence and synchronization will tell what action is enabled to be executed
• The process logic will tell the orchestrator if a given task should actually be triggered
• The actual execution will be performed by the orchestrator.
• Several actions can be triggered in parallel, each branch having its own process logic. The merging of branches is also done by the orchestrator
• When required, non-merging branches (or autonomous branches) can also be modeled.