Kimbo,

BPMN is not that hard! .

Here are a few pointers:

1. Read the van der aalst patterns at http://www.workflowpatterns.com/ (they are not using BPMN but YAWL for Yet another workflow language)

2. Read Stephen Whites attempt at replicating the 21 patterns (see http://www.bpmn.org/Documents/Notations%20and%20Workflow%20Patterns.pdf). Since you know UML you'll see that some of the patterns cannot be done in BPMN

3. Read "Essential Business Process Modeling" - (2005) Michael Harvey -(ISBN 0-596-00843-0)

4. Dowload Bizagi and replicate some of the patterns (www.bizagi.com) and then generate documents (you can also do the same with Enterprise Architect)

Note, Holoscentric is an excellent tool; however, their process maps are more akin to DFDs (the owners would probably shoot me, when next we meet). They now have an implementation of BPMN. Overall its a terrific tool, they doing quite well at AGIMO ( see http://www.finance.gov.au/agimo/index.html)

warm regards,

K

Ps. I'm not associated with EA, Holoscentric and BAPM

It would be nice if we could find a common language that satisfied everyone's needs. That was the original purpose of UML, to set a common notation and set of standards for object modeling. Use Cases were added by Jacobson in a later verion. The activity diagram was an enhancment of the state transition diagram, which allowed use cases to be described graphically, as STDs did for classes.

Business use cases were added at an even later date, sometime around when the RUP was released. I do not see why UML should not be used for business modeling. It has all the tools that I need and a lot more that I don't.

The of UML was the class .. that is until Jacobson got involved and made the use case the building block from which everything else is derived.

I have never used BPMN, but from what I have seen on this site, it appears that UML is a more powerful modeling language.

Obviously it would be more efficient if all BAs used the same modeling language, that fits their needs .. I know that wasn't the original intention of UML, but I see no reason why we could not take a subset of UML and define a BPM Language from it.

Leslie.

Not long after I started training people in how to use the UML effectively in the context of the Iconix process, I came up with term "magic triangle" to describe what seems to me a potent combination of artifacts. Specifically:

1. protypes (which includes anything that provides a picture of a UI, from a sketch on a napkin up the chain)

2. use cases (which are, of course, part of the UML)

3. domain model (made up of UML class diagrams)

Each of these pieces does something well. The combination, with each piece reflecting some things that complement the other pieces, is powerful.

So, why am I bringing this up here?

Two things. (1) There's no reason why people shouldn't learn how to write and/or use use cases because of fear of the UML. Use cases are about capturing what a system needs to do, specified in user-friendly language. (They were a part of the Unified Method early on, albeit a late addition. They've never really been a full player, partially because Dr. Jacobsen was late to the party and partially because they're, well, text-based in the context of a primarily visual langage.) (2) Class diagrams are indeed at the conceptual center of the UML, but that does NOT mean that people should be afraid of them either. They're excellent at capturing the vocabulary of a project, when expressed at the appropriate level of detail (which is to say, just names of classes). These are, in my mind, absolutely fundamental tools in the BA toolbox.

I'd say that a BA should also know his or her way around activity diagrams (UML 1.x version, at least; I have some issues with UML 2.x activity diagrams, which I think introduce unnecessary complications), definitely. Judicious use of state diagrams to show the lifetime of objects at, again, a more conceptual level is also a very handy technique. As far as the rest of the UML, I think you just have to avoid the temptation to dive too deep too soon, but as someone pointed out, the more tricks you have in your bag, the more flexibility you have.

I'm not much on 1-10 scales, and of course, I'm (more than) a little biased, so I'm going to avoid reducing what I've said here to a solitary number. I do think, however, that since the UML was explicitly built on the premise that use of it would improve communication between and among project workers and stakeholders, there's very good reason for a BA to learn the language, and for said stakeholders to be open to learning those aspects of the language that will add value to their lives.