We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

James Taylor's Decision Management

James Taylor

Some thoughts on the fallacies of business process execution

Vote 0 Votes

Jean Jacques Dubray has just published an interesting article over on InfoQ called The Seven Fallacies of Business Process Execution. I took the time to read it carefully as I like JJD's perspective (and not just because he liked my book). Anyway, he lays out 7 things he considers fallacies common in discussion of business process execution and I thought I would comment on a few of them.

  • Fallacy #1: Business analysts model their processes from a systems' point of view
    An not only do they not model their processes from a systems point of view, they don't think of the rules in the decisions within those processes from a systems point of view either.
  • Fallacy #3: Business analysts should be able to create executable solutions from process models
    Not only is this not terribly useful, nor is having business analysts create executable business rules except where some sort of framework has been developed to allow them to work in business terms while executing efficiently in systems terms.
  • Fallacy #4: If we add a magical BPMS that create solutions directly from business analysts inputs we would not need to develop any of integration with existing systems nor to change existing systems of record nor to do any QA.
    Clearly a nonsense proposition - you will still need to handle some of these technical and IT-centric tasks for processes and, indeed, for rules. He quotes Marlon Dumas (from Bruce's blog) as saying "You won’t remove the developer from the BPM lifecycle, simply because no business analyst will ever be willing to write something that resembles an XPath expression, or any other expression language." While this is true, plenty of business analysts are quite capable of manipulating business rules in a declarative, expressive, verbose syntax or using template-driven environments. XPath is how a programmer does this, business rules are how analysts can.
  • Fallacy #5: Business Process Execution must be centralized
    While I mostly agree with him, I take issue when he says "The information systems are simply here to advance, capture and report the state of these resources and activities" as I think this is old thinking. There is no reason why this information systems cannot also decide how to act - they don't need to be as dumb as they typically are. I did like his Figure 4 as the Implementation of the Job Application Service shows a nice decision service(wiki) Validate Application - as part of the solution.
  • Fallacy #7: Bruce Silver concludes his post by saying that "the collaborative implementation paradigm, in which executable design is layered on top of the BPMN model, is the way to go.
    While I am not qualified to participate in this debate over standards, I do think that collaboration is key - business users and analysts must be able to collaborate with IT to define processes and decisions and to allow the business-focused staff to take on more of the work in many updates and changes to processes and decisions over time. Indeed Bruce once posted on how much BPMS vendors could learn from BRMS vendors in this space and I have a wiki entry on how to empower business users.


James Taylor blogs about decision-management technologies such as predictive analytics and business rules, discussing how they deliver agility, improve business processes and bring intelligent automation to SOA.

James Taylor

James Taylor blogs on decision management for ebizQ, and is an independent consultant on decision management, predictive analytics, business rules, and related topics.

Sponsored Links



 Subscribe to this blog by RSS
Subscribe by email:

Recently Commented On

Recent Webinars

    Monthly Archives