How to map data to BPM task

Hello Paulo,

I have a humble suggestion from my practice:

Use the Cluster as the business object at process level. The cluster represents the "case file" that is handed through your process. Literally remember the old "paper process world": A file containing all sorts of sheets of paper landing on someone's desk to do something with. So it is a composed object. Use an "object assignment diagram" (non-standard, see below) to specify, what is in the file. In contrast to Uwe I would demand, that this object is stateless. If you produce a car in a process of dozens or thousands of steps you would go nuts modelling all intermediate states and when the engineer changes the design a bit you go modelling another state.

So the Cluster is the (stateless) business object. We have made up our own "object assignment diagram" where we assign objects from an object model at conceptual level to the cluster, thus describing what objects of the real world may occur in the case file. That conceptual level object model is described in IE data models. Additionally the "object assignment diagram" may declare relevant business object states (modelled as objects of type Product/Service). These may be shown in EPC, if you like.

The logical level of data modelling takes place in diagrams of type "Data type Diagram (Solution design)". Essentially these are in IE data model notation, but have slightly different symbols. There may be many of these. You will have at least one, describing a "canonical data model". That is the central reference for data integration on an ESB for example. There may be more data models for each application.

For mapping from the conceptual object model to the canonical data model and from the canonical data model to application specific data models you could use matrix models.

It is important to note, that the business side is responsible for the conceptual level object model, describing the (real world) object model and terminology of the business, while the canonical data model and application specific data models are in responsibility of IT. Ideally the definitions in the conceptual object model map exactly to the canonical data model. The canonical data model will add some technical necessities such as keys and message envelopes.

Specifically, if you want to get views for each BPM task and you are going through the effort of designing a new BPM workflow application, it is useful to collect user requirements in task specific "screen design" models. There you can visually collect the requirements, which d-attributes should show on a task specific screen. There you can "harvest" the d-attributes and allocate them in your conceptual level object model, thus enriching it with attribute level detail and possibly discovering gaps. This way you grow your conceptual level object model task by task. That is also often a concern that you cannot invest in developing an object model for the whole company. It can come as a by-product of your projects and grow successively as needed.

Regards, M. Zschuckelt