Wednesday, February 24, 2010

Why in Oracle BPM Automatic Activities Belong to the Automatic Role (at least one of the reasons)

Strictly speaking, an automated activity does not have a human actor as role involved, and from that perspective the automated one does not belong in the swim-lane of that role, but in the one of the "automatic" role instead.

You may say that this is smells like over-designing the thing, and moreover it takes extra space, so rather not.

But there also is a practical edge to this. I happened to notice that there are certain circumstances in which automatic activity can actually show up in the workspace of people having that role. That can happen when the automatic activity takes some time to complete, and (if memory serves me well) I also saw this sometimes happening with timers. Very confusing for the user, because it looks like he or she has something to do, while the workspace does not allow doing so.

I therefore recommend always to put automatic activities in the "automatic" role, at least once you start implementing the process. The obvious exceptions being automatic activities inside a screen-flow.

How to Recognize the Requirements in Use Cases?

One of the core values of using a method is that it provides a common "language". That holds for all kind of methods, including those for software engineering. It for example helps when everybody has a same understanding of what a "use case" is. It also helps to have a common format for use cases. Similar to the agreement that (at least in the western culture) we write from left to right, top to bottom, contents at the beginning, index at the end. As is the case with a book, you will appreciate that a common format for use cases not only helps those writing them, but especially those reading them (business as well as IT people).

Next I will discuss a format that I have learned to appreciate very much, and can recommend to everyone who is writing use cases.

If you have not already decided upon a common format, or when you have the opportunity to do so, you may consider writing use cases in a two column format. I learned this technique more than a year ago from a great guy called Vince Bordo (hi Vince!). I practice this technique since then, as I find it to be more effective than what I used to do (i.e. a one-column format).

In practice this looks as in the following example, which is a reformatted version of a use case I used in some previous posting:

The beauty of this format is that it visually depicts what the system needs to do in order to satisfy the requirements, as that is exactly what the right column is about. The left column describes how actors (primary as well as secondary) interact with the system in order to satisfy the goal of the use case.

In theory (I would not try this in practice, but in theory) you should be able to cut out the right hand column of the use case and only hand that over to the developeras and tell them that this is what they need to realize. That, plus the supplemental requirements of course.