> This is a question, not a comment: With BPDM, does the
> BPMN serialization describe the semantic or the notation?

Serialization would be the XML documents, is that what you mean? Serializations are inherently notational, because they capture the diagrams being interchanged. They use the most concrete concepts only, rather than abstractions.

Metamodels contain at least concrete concepts, because serializations conform to XSD or XMI generated from metamodels. Semantic metamodels, like BPDM, also include abstract concepts for semantic elements that are defined once and reused many times across the metamodel and in other metamodels. This facilitates uniform implementation and understanding of the specification, as well as integration with other tools in industrial, enterprise-wide architectures. This is critical for BPMN tools, since they need to work in a larger context of enterprise applications. The abstractions are not visible in the user’s XML documents, of course, because these are purely notational.

> E.g., Would the XML for an implicit parallel split (2
> unconditional sequence flows out of an activity) be the
> same or different from the case of AND-split gateway? In
> your understanding would that apply also to the
> IBM-SAP-Oracle one or not?

Both BPMN-S and IOS would capture the above cases differently, because metamodels must represent concrete concepts to support serialization. BPDM has the added benefit of providing abstractions of these concrete concepts, as described above. For example, BPDM has a single abstraction for the semantics that process definitions can occur (be performed/executed) many times. In the above cases, BPDM explicitly models that occurrences of the process (the individual performances/executions at certain times) will be linked to occurrences of other processes corresponding the activities connected by the gateways and sequence flows, and that the temporal order of these other occurrences will be as required by the gateways and sequence flows. Purely notational metamodels, such as IOS’, only represent that activities appear in the diagram, and have sequence flows and gateways between them. The meaning of this for actual occurrences left completely to textual description.

Conrad

Now if that’s all you read, you might think, as Mr. Malik seems to, that this claims you can hand over process design and implementation to business people “right now”, but in context, what Fingar & Smith are presenting is a vision, a goal, a direction to be heading in… no you can’t do that right now and no, they are not suggesting that you can… but they are saying that this is the goal of BPM and where it is heading… so there’s one response to your challenge… and right behind Fingar & Smith there were a many others, myself included, who made similar statements - to set the vision - for the direction to be moving in. Heck, that was what BPML & BPMN and remember “BPQL”? They were supposed to be one of the steps toward that future.

However, too many times people heard that and felt threatened or just refused to believe that we would ever get to such a place. I know that it is possible and that we are not as far away as we thought we were in 2003-2004 when those kinds of goal statements were more common. So concentrate on real issues… admit it when you (we, whoever) slips in a little hyperbole and move on… swift-boating? I think not. Confused - yeah sure, but it’s easy to get confused by all the tons of stuff you have to wade through to find anything useful or interesting these days…

I remember when the same “controversy” went on in data management when “real DBAs” laughed at the idea that RDBMS and the design principles it brought with it was totally impractical - it’ll never work, too slow, and that SQL (& QBE) what a joke- first of all, it’s too weird, and users will never be able to write their own queries and even if we let them try, they’ll just screw things up… well, for a few years, they were kind of right, but it didn’t take very long at all until RDBMS was the dominant model and all that other stuff was a drag on progress and we got rid of it as quickly as we could. So let those who are “slow” (conservative, unchangeable, entrenched, whatever) alone. Be nice to them. Feel pity for them, because they will still be trying to figure out what happened long after the world has moved on and left them sitting there playing with their mud pies
.

George Barlow
VP & General Manager, Appian Anywhere

I would say there are a lot of scenarios where you really want to know “start” as the moment a user starts the activity. So, a time-based escalation might not need to happen if a user has already “started” the activity, but should happen if no user has started it yet… etc.

(like you, i don’t care what the specific diagram choices are - I’m not iconographer

scott

> the question is whether BPMN 2 should use his own
> metamodel or if it should include another metamodel
> (BPDM), which was not directly defined for BPMN.

BPDM was defined with BPMN in mind and integrates quite alot of the terminology already (Process, Activity, Gateway, etc). The terminology can be further aligned in BPMN 2, and where it can’t, BPMN is a specialization of BPDM. Having two similar metamodels adopted at OMG is a significant burden for everyone. Also see the comments at http://www.brsilver.com/wordpress/2008/05/06/an-insiders-view-of-bpmn-20.

The BPMN metamodel needs abstractions because business modeling, and even process modeling, goes well beyond BPMN as a notation. A diagram-specific interchange format cannot meet the realities of a marketplace where BP, EA, and SOA methodologies are used together and will evolve over time. There are and will be other notations and other interchange formats. It is the job of the notation to be user friendly and provide a specific view that is comfortable for its intended users. It is the job of the metamodel behind the view to capture the semantics of the many views required for realistic architecture efforts.

For perspective, let’s remember the market’s most immediate concern is diagrams and serialized interchange, not metamodels. We have a fully standardized metamodel that supports user-friendly XML documents via XSD, has a mapping to BPMN 1.x notation, and in the next BPMN 2 submission will capture purely graphical information such as activity positions. We can get to an interchange format much more quickly with a BPDM-based approach than waiting for an entirely new metamodel to be developed, mapped to XML and notation, integrated with graphical information, and worked through the standardization process.

Conrad, Cory, Fred