Thursday, October 11, 2012

BPMN Naming Conventions

So far I have not found many references discussing BPMN naming conventions, and there is no official one. So I thought I share a few of mine that I developed over the years. Hope you can make use of it.

Most of them are captured in the following picture.


Unfortunately I cannot depict them all, so here are a few more:
  • Do not use the component type name in its name, for example do not use Expenses Process, Submit Expenses Activity, Expenses Rejected Exception.
  • Name a process so that its name fits in the following phrase: "the [Process Name] process", for example: "the Order Handling process".
  • Give an activity a short, but meaningful name. So:
    • Don't use uncommon abbreviations,
    • To keep the reader focused on the keywords, do not capitalize prepositions and possessive pronouns ("Review and Finalize Order"),
    • Avoid articles and pronouns ("Add Order Lines" instead of "Add all Lines to the Order").
  • Name Catch Events, Business Exceptions, and Signal Events so that is reads like an answer to the question: "What happened?", "Well the Customer Cancelled".

Like most naming conventions, the prime reason is to have consistency. So don't treat it like a religion, and don't think that mine are better than yours. Of course they are, but just don't think that. Most of them are more like a guideline.

To help you with your choice, consider this:
  • Using active verb-noun phrases is a psychological thing. Don't ask me why but somehow it helps your brains to determine the right scope of an activity. For example, one person may interpret Order Handling as one single activity (done by one person as one logical "transaction") while some other guy considers it to be a complete process. If you call it Handle Order that just "sounds" more like one single activity. It is not for nothing that this also is a de facto standard for use cases.
  • Using the question mark for exclusive gateways helps with limiting the amount of text you have to put in the diagram, as all conditions on the outgoing sequence flows read as a simple answer to the question of the gateway.
Let me know if you have some more, or when yours are better than mine!

6 comments:

Anonymous said...
This comment has been removed by a blog administrator.
Anonymous said...
This comment has been removed by a blog administrator.
Martien van den Akker|Darwin-IT said...

Hi Jan,

I think your conventions are fine. As an addendum: in the BPM11g OPN course it is stated to use Hungarian (java camelCase) notation for variables starting with a lowercase (like you would with a java variable or method-name). Use meaningful names for variables and differentiate between project, proces, activity variables and arguments (don't use the same name on different levels with overlapping scope).

Hope this helps as well.

Regards,
Martien van den Akkker (blog.darwin-it.nl)

Jan Kettenis said...

It sure does Martien. Not coincidentally it is in line with the conventions we use for my current customer.

To add to this: it is good to realize that when you want to change the level of a variable that already is used, you just have to create it at the one level and delete it at the other one and the code keeps on compiling/

Jan Kettenis said...

It sure does Martien. Not coincidentally it is in line with the conventions we use for my current customer.

To add to this: it is good to realize that when you want to change the level of a variable that already is used, you just have to create it at the one level and delete it at the other one and the code keeps on compiling/

Ivan said...

I think "BPMN: Method and Style" book by Bruce Silver provides excellent set of BPMN naming convention.