Comments on: A chance encounter with jBPM http://www.column2.com/2008/02/a-chance-encounter-with-jbpm/ BPM, Enterprise 2.0 and technology trends in business. Fri, 19 Mar 2010 10:19:34 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Jeff Wallk http://www.column2.com/2008/02/a-chance-encounter-with-jbpm/comment-page-1/#comment-8285 Jeff Wallk Mon, 23 Jun 2008 18:18:09 +0000 http://www.column2.com/2008/02/a-chance-encounter-with-jbpm/#comment-8285 Perhaps one of the limitation with current thinking around BPM is the focus on flow-centric modeling instead of discrete functionality whose behavior is controlled by rules & metadata. Typical BPM efforts attempt to weave these into a "diagram", which further obfuscates the problem (and complicates the solution). The problem with most of these diagramming tools is that they don't support business rules modeling. Once that hurdle is passed, then complexity can be abstracted in rules not the hard-coded process flow (which is our current conceptualization). Perhaps one of the limitation with current thinking around BPM is the focus on flow-centric modeling instead of discrete functionality whose behavior is controlled by rules & metadata. Typical BPM efforts attempt to weave these into a "diagram", which further obfuscates the problem (and complicates the solution). The problem with most of these diagramming tools is that they don’t support business rules modeling. Once that hurdle is passed, then complexity can be abstracted in rules not the hard-coded process flow (which is our current conceptualization).

]]> By: Sandy Kemsley http://www.column2.com/2008/02/a-chance-encounter-with-jbpm/comment-page-1/#comment-7380 Sandy Kemsley Mon, 25 Feb 2008 13:50:36 +0000 http://www.column2.com/2008/02/a-chance-encounter-with-jbpm/#comment-7380 Paul, thanks for your insightful comments. We definitely need to have a way to bring together BPM and BRM in the minds of both business and IT -- they do seem to be considered as quite separate technologies within the customer organizations that I see. Paul, thanks for your insightful comments. We definitely need to have a way to bring together BPM and BRM in the minds of both business and IT — they do seem to be considered as quite separate technologies within the customer organizations that I see.

]]> By: Sandy Kemsley http://www.column2.com/2008/02/a-chance-encounter-with-jbpm/comment-page-1/#comment-7379 Sandy Kemsley Mon, 25 Feb 2008 13:48:53 +0000 http://www.column2.com/2008/02/a-chance-encounter-with-jbpm/#comment-7379 Sebastian, was your comment intended to be attached to one of the posts about ProcessWorld rather than this one about jBPM? The graphical merge functionality is interesting, and likely related to their new versioning capability, in which differences between versions are shown. Sebastian, was your comment intended to be attached to one of the posts about ProcessWorld rather than this one about jBPM? The graphical merge functionality is interesting, and likely related to their new versioning capability, in which differences between versions are shown.

]]> By: Paul Haley http://www.column2.com/2008/02/a-chance-encounter-with-jbpm/comment-page-1/#comment-7297 Paul Haley Tue, 19 Feb 2008 16:24:16 +0000 http://www.column2.com/2008/02/a-chance-encounter-with-jbpm/#comment-7297 It is good to see some clear thought and concern for the limits of the flow-centric emphasis of most BPM. As with procedural code, the more you try to model a real business, the more complex and tangled the flowchart becomes and, consequently, the more maintenance becomes a technical matter at which even the most skilled become less productive as the "logic" grows. As this happens, it certainly drifts from a business model to an implementation. We believe the cure involves both an emphasis on decisions (not just from the BRMS side, as advocated by James Taylor, but also from the BPM perspective) and a more knowledge-centric approach. This knowledge centric approach should include decisions, obviously, but also the vocabulary (e.g., SBVR) and ontology (i.e., the model). Until BPM and BRM share vocabularies and models, BPM mayappeal to the business but be largely confined to IT. Parenthetically, I believe that JBOSS, which has both the jBPM platform and JBOSS Rules / Drools, is positioned fairly well to lead the converging markets in this regard. It is good to see some clear thought and concern for the limits of the flow-centric emphasis of most BPM. As with procedural code, the more you try to model a real business, the more complex and tangled the flowchart becomes and, consequently, the more maintenance becomes a technical matter at which even the most skilled become less productive as the “logic” grows. As this happens, it certainly drifts from a business model to an implementation. We believe the cure involves both an emphasis on decisions (not just from the BRMS side, as advocated by James Taylor, but also from the BPM perspective) and a more knowledge-centric approach. This knowledge centric approach should include decisions, obviously, but also the vocabulary (e.g., SBVR) and ontology (i.e., the model). Until BPM and BRM share vocabularies and models, BPM mayappeal to the business but be largely confined to IT.

Parenthetically, I believe that JBOSS, which has both the jBPM platform and JBOSS Rules / Drools, is positioned fairly well to lead the converging markets in this regard.

]]> By: Sebastian http://www.column2.com/2008/02/a-chance-encounter-with-jbpm/comment-page-1/#comment-7277 Sebastian Sun, 17 Feb 2008 19:38:57 +0000 http://www.column2.com/2008/02/a-chance-encounter-with-jbpm/#comment-7277 The new version of ARIS SOA Architect provides a graphical merge functionality. You can transform a business process model into BPEL and change the BPEL as well as the business process model. If you transform again, it will detect conflicts and the user can solve them using the graphical tool. This is a little like a diff tool for ascii files, but here in a graphical way for process models. The new version of ARIS SOA Architect provides a graphical merge functionality. You can transform a business process model into BPEL and change the BPEL as well as the business process model. If you transform again, it will detect conflicts and the user can solve them using the graphical tool. This is a little like a diff tool for ascii files, but here in a graphical way for process models.

]]>