Comments on: What If BPMN Were a Modeling Language?

By: marlon_dumas

marlon_dumas — Wed, 09 May 2007 05:22:06 +0000

Patrice, Bruce
If you want to read some “stories from the trenches” on the differences between process models at the level of the “business analyst”, at the solution architect’s level, and at the software developer’s level, I recommend the following experience report from a guy at Danske Bank:
http://www1.itu.dk/graphics/IT.....007-96.pdf
In particular, I like the three types of typical mismatches that he identifies between the “analyst” process models, the “architect” models and the “developer” models:
1) Lack of details about exceptions: “During the initial unit test of the workflow, it turned out that the solution model [given by the architect] only considered the “main” road of the process, i.e. the process of handling a customer package when everything was as expected. Many exceptions and special cases were not covered.”
2) Activities not broken down sufficiently: “…an activity was described as “create all cards”. When the developer should implement such an activity, he had to consider if a new service should be developed to create a bunch of cards, if an existing service for creating one card should be called several times in a loop structure, and what should be done in case of failures when creating the cards? Such decisions are not implementation issues; it is decisions that should have been modeled in details in the [high-level] model.”
3) Underspecified dependencies between activities: “Activities in a process may depend on each other. For instance, an account must be created before creating a card. Such dependencies were not always described explicitly and the developer had to figure out how to organize the control flow. These dependencies should have been described in the [high-level] model.”
4) Missing data (data that is needed but not gathered anywhere): “The architect had not considered which data to use when defining service invocations or user interface based activities. Both activity types may require data that is not present and that has to be retrieved from somewhere else.”

By: bruce

bruce — Tue, 08 May 2007 17:03:58 +0000

Patrice,
I agree with you that BPMN spec does not do a good job separating attributes needed for execution from attributes needed for modeling. In fact, there are rules that specify certain attributes that I consider implementation-related MUST be populated if some diagram element is drawn. I don’t agree, but see my recent post about IDS Scheer and BPMN — they consider it an executable design notation not a modeling notation.
As for your example, I think you point out an area where implementation detail pollutes the model. It is of course possible to have one message end event representing two different possible messages, one success message and one fail message. At the abstract level, what is to prevent this? When you attach a message attribute to the event, in the case of BPEL generation you might specify a wsdl messageType. Even so, a single messageType could be used for both success and failure messages (as long as they both used the same schema). But if success and fail messages are different messageTypes, then I suppose you would need a gateway and two different end events. This is an example of the kind of implementation-specific restrictions that I think have no place in process modeling. They are strictly design issues, because a different execution language might have different rules. Besides, your BPMN tool’s BPEL generator probably ignores those attributes anyway… all that worrying for nothing!
–Bruce

By: Patrice

Patrice — Tue, 08 May 2007 16:02:39 +0000

Bruce,

If i’m understanding you well, you say that on one hand portability will be hard to reach regarding implementation model and on the other hand that you look for portability of the abstract model level.

I fully agree with you and would also at least expect that level of portability at Modelling level.

My point is that in today’s communication around BPMN is not that obvious on the goals BPMN tries to achieve often the text talk about implementation while examples are abstract models.

I think it can deserve both puposes but it would help having some guidance on which properties do I need to fill in case of modelling and which in case of implementation.

I will take another example i’m facing. Let say I have to close an activity once it has been performed. That closure will defined a closure code stating whether the activity has been successfull or not. According to BPMN the message is not represented by the event. Saying so, in my process I have one end event (type Message) that will notify the end of my activity process, the message linked to that event containing the status code. While looking for implementation, It appears that in case of success I will apply one type of message while in case of failure I will apply another type of message. As in my tool I can link only one type of message to the end event I’m facing the fact that I need to have a gateway before the end event and then two separate end events to show that implementation.

As a conclusion I would say that there are two different usages of BPMN and the two don’t follow the same “rules” and use the same properties. And so we should first define what kind of usage and then define what kind of portability we expect for that usage.

Patrice

By: bruce

bruce — Tue, 08 May 2007 10:41:43 +0000

Patrice,
You make a good point, that business analysts should be able to put such details in the model. I don’t disagree with that. The problem is that these details are the part that is hard to make portable across tools, unless you are willing to make them essentially text annotations. I said that BPMN has no place to put implementation details. Actually it does provide many attributes for that purpose, including data parameters, messages, etc., nominally for BPEL generation, although the BPMN tools frequently ignore those attributes in their BPEL mappings, and they generally don’t follow the naming conventions used by the BPEL tools, either. Actually, there is no common naming convention across tools. I think what I am trying to argue is that just because BPMN cannot support such implementation detail in a portable way does not negate the need for portability at the abstract model level.
–Bruce

By: Patrice

Patrice — Tue, 08 May 2007 07:36:46 +0000

Bruce,

But still my process end user may still define requirements on what they are willing to perform manually and what they expect the tool will compute for them even at this level of details.

And as I can draw a valid BPMN schema for both representations of my example, it is not easy to define where the bordeline is lying.

I’m am kind of fighting with business analysts to have them focusing on the E2E process and not on the implementation of the tool that will support the process. However, at the end we should deliver the requirements for the tool implementation. In this situation it’s a bit me who’s going schizophrenic ;o)

And I guess that at the end, every business analyst as to deliver a diagram that will support/define his requirements on the tool he wants to support his process.

Currently, I’m telling my business analyst to focus on the WHAT (meaning the E2E process) and not on the HOW (meaning implementation) and if such specific constraints are required on the implementation , I ask them to put them in the task documentation.

When you say BPMN has no place to store that kind of information, IMHO, it should to deserve that dubbel vision it supports.

Patrice

By: bruce

bruce — Mon, 07 May 2007 15:43:57 +0000

Patrice,
In a way your example is a good illustration of the difference between a model and an implementation. As a model, all you might need to record for the task in BPMN is its name and resource. How the calculation of the activity start and end dates is done is an implementation issue; BPMN has no place to store that information anyway. The purpose of the process model is to put that task and resource assignment in context with other tasks, gateways, events, etc in the end-to-end process… independent of those details.
–Bruce

By: Patrice

Patrice — Mon, 07 May 2007 14:06:10 +0000

Hi All,

I’m a bit puzzled with all this discussion! Firs of all, I’m not used with all these BPEL, MOF and BPDM stuff. I’m currently using BPMN to document Business processes from a business point of view which is I think one of the usages BPMN stands for. Secondly, for me the borderline between process modeling and implementation is not clear and this leads to that schizofrenic perception we can have while tryi!ng to use BPMN.

Currently, I’m struggling with a project where I have to define the requirements to implement a process and I’m coming with this simple example. (Sorry Can’t paste a schema in the comments)

1) Let imagine that within my process I have a task “Define activity planning”. From a business perspective, all I need to know is that a start and an end date will be defined for an activity. Maybe in some simulator I want to be able to define that this task will not last more than 1 hour, will not take too much ressources, …

2) Now from an implementation point of view, I can tell that the start date will either be defined by the end date of some predecessor or that the user will type it in. For the End date, I can say that it will either be calculated from the start date plus the duration or that the user will type it in, the duration being calculated from the two dates.

So far it’s kind of easy!

But looking at the implementation of the start date, I’m now digging back into my process and asking myself what should happen if the predecessor is not defined and trying to model this requirement one way or another! But here the model I have to come with is not that much related to my business but to implementation!

So IMHO, defining a standard and portable XML structure should first bring clarity and specification on the borderline between process modeling and implementation and make it clear I’m documenting from a business perspective or from an implementation perspective.

Thanks and have anice day,
Patrice

By: juan_cadavid

juan_cadavid — Sat, 05 May 2007 03:52:37 +0000

I got your point now, and the importance on the portability remarks. Mavrik_eka couldn’t do better the wishlist for a BPM modeler.

Yes, I agree a standard can’t be defined based on a particular implementation of a modeling facility, as great as EMF can be. Intalio did propose a schema, but not a standard, which we are still lacking of. Sure they got a really cool BPMS around, but it won’t guarantee that I’ll need to load the models somewhere else to add implementation information and then bring it back.

We have to realize that the OMG created a standard to create modeling standards (intended word repetition), which is MOF (Meta Object Facility). This is what allowed UML to be serialized and hence made XMI possible, letting us exchange models between CASE tools. It did work but not entirely, and still they want to repeat the same story again with business processes. They made BPMN theirs, and now they are building the MOF based BPDM, to allow us (among many other promised features) exchange BPMN models. It’s just that they haven’t published the XML schema (a genius OMG specification reader should be able to put it together by looking at the MOF diagrams in the spec).

An idea that I’m having is to grab Intalio’s schema and rebuild it not on Ecore (which is Eclipse’s MOF reference implementation) but on pure MOF, using pencil and paper if you will. Then you will have a true pure metamodel, and from there on, the standard XML schema is just steps away. Of course, maybe with BPDM’s XML schema this won’t be necessary, so we’ll just have to wait and see. Course of things is getting more and more interesting.

-Juan

By: bruce

bruce — Thu, 03 May 2007 17:48:21 +0000

Tom,
Your note is very encouraging… the first one that indicates anyone has some idea of what I’m talking about. Yes, portability of process models (as opposed to execulabble designs) is what I’m talking about. But the bit about analysts drawing doodles and expecting some implementation to result is a familiar straw man. I think it’s just false. Many business analysts dont even understand the idea of BPM as a process automation and monitoring platform, i.e. they do not even have the concept of an “executable model.” The ones that do accept (today at least) that the implementation is BPMS-specific, even with BPMN-based tools, like Appian, Tibco, Lombardi, Savvion, Intalio… Still, most of those tools keep the BPMN view in sync with the implementation. What they don’t do is let another tool’s BPMN view stay in sync with their implementation. If the goal of BPDM or the Intalio/Eclipse Foundation efforts is to standardize BPMN at the executable level, that’s interesting but in my opinion not really the primary need of the mainstream BPM community today.

If there were such a pure modeling-focused schema and validation ruleset in existience, I have no doubt it could be unambiguously mapped to BPDM for implemenattion. Any process modeler understands that the implementation platform is going to impose more precise semantics on the model than that modeler had in mind… or, more likely, has any interest in at all.

By: mavrik_eka

mavrik_eka — Thu, 03 May 2007 13:51:32 +0000

Focusing on model portability is one key aspect. Focusing on portability from an implementation standpoint is another aspect. I am not saying one is more important than the other. As you have stated there are strong reasons to focus on model portability.

That being said, I was wondering if true end to end portability - model + implementation would ever be a reality and if yes what would that look like in the future. With BPEL 2.0 being ratified there seems to be a lot of talk around interoperability and portability of processes as a key advantage. The fact that XPDL is not / does not have an execution language puts it at a disadvantage.

Obviously for customers who want management discipline around their processes this is not relevant but for all the customers buying BPMS tools from IBM, Oracle, BEA, Savvion, Lombardi, Pega, TIBCO etc. where the focus is on modeling and implementation there is some confusion.

From an end to end portability standpoint, is BPMN + XPDL a better long term viable option or is BPMN + BPEL + Extensions (human interaction, subprocesses, WSIF, BPEL4J etc.) a more viable option? In both these cases, would we get round tripping once we take a model and add implementation specific stuff around it? Would we be able to model in one tool, add implementation specific stuff in another, bring it back to the modeling tool and make changes and then execute all without any loss in translation?

Or is end to end portability a pipe dream that will never be achieved and we need to accept that.