Start a Discussion
BPM
user-pic

Why are Business Rules Subjugated to Process Management When Business Rules Should be Leading Process Management?

Vote 0 Votes
JP Morgenthal: Why are business rules subjugated to process management when business rules should be leading process management? That is, the business rules should be dictating which processes to execute and when, so why are they considered a sub-component of BPM?

20 Replies

| Add a Reply
  • This is an interesting quandary. Business rules can be very specific and drive business processes, but just as often, they represent general practices that can be shared across multiple business processes - for instance different industry vertical units might share some billing rules, but have different methods for handling returns and customer service.

  • JP, way to spark some controversy again!

    I have to say, the whole question is off-base. *Starting* something is not the same as leading. Is the center in football leading the Quarterback? He determines when to hike the ball, so why is he subjugated to the quarterback?

    If we take the word "Lead" out of your question and ask the real, underlying, less controversial question: "Why aren't business rules used to start BPM?" Well, they often (I hate to use absolutes like "always") are.

    The reason most people think of rules as a "component" of BPM is because during the process, the process will leverage rules of various kinds to determine which branch to traverse in the process. Or who to assign the next task to. Or whether, given the process data collected, this entity is a good credit risk. At that point, rules are like any other integration point in some sense - I call with inputs, I get back an answer, and then proceed. It doesn't really matter to my process whether it is a rule behind the scenes - a rule, a db lookup, a Java API call to some other system. So, certainly within the process, the rules are at the mercy of the BPM - only called when wanted, duty-bound to answer when asked, and not in control of the contextual information available to BPM.

    You could describe everything that happens in BPM as a rule, rather than using BPMN diagrams, etc. -but a very few people would understand the result. You could also describe it all in fortran. Or machine code/Assember. But again, no one would understand the result.

    Rules are simply not the pre-eminent way in which humans understand their lives, their work, or their processes. BPM hits closer to the mark, leaving plenty of room for improvement.

  • Well, I was ready to say ‘I agree with Scott’ until read his last statement about “BPM hits closer to the mark, leaving plenty of room for improvement.? Does it mean that BPM deliberately degrades importance of the rules to leave a “room for improvement??

    I think that the question is a ‘Why rules consider a part of BPM and not …opposite?! ‘ BPM is not a process it is about process modelling/management/measurement/etc. A process needs to make a decision about next step; this where it uses rules. These rules can easily lead to starting another process, and so on. It is impossible to say where is the chicken and where is the egg. If you abstract a process into a service, i.e. view it as business objectives, goals and input/outcome data, rules disappear. However, you still can continue BP modelling at the level of business tasks/goals keeping in mind that your entities are processes (ordered sequences of activities). The only small thing needs a correction – it is not more process modelling, it becomes service modelling and service composition/collaboration modelling.

    Rules are considered as sub-components of BPM (note – not subcomponents of process) because they can exist without and outside of a process. While rules may be shared by processes, the combination of rules must be unique to identify particular process. Two processes may have the same business objectives, goals and input/outcome data, but if they have different rules and/or different order of the rule application, they are different processes. Otherwise, they cannot be distinguished.

    My last note is that BPM considers rules as sub-components but it does not own the rules. Rules may be externalised from any process and provided by services to any consumer. Thus, if a process appears to the outside consumer as a service, if the process uses services to perform its actions and engages other services to make business decisions (via rules), what has actually left from the process in this picture? Or Scott would say that “no one would understand the result?? I would disagree. A lot of people would understand that they deal with services but they would not care how the services are engaged if they provide desired result. So, who cares about the process except the people who are paid for the process to run?

  • Scott, re: sparking controversy, I aim to please! :-)

    Now, let me work backwards on your response:

    "Rules are simply not the pre-eminent way in which humans understand their lives, their work, or their processes. BPM hits closer to the mark, leaving plenty of room for improvement."

    We drive the speed limit, we don't chew gum in class, we don't spit into the wind, we tug on Superman's cape, we don't pull the mask off the ol' Lone Range and you don't mess around with JP. Rules are the most pre-eminent way humans understand life, but go ask someone to follow a process to get a task done and you will see how quickly the human eye can roll back in its socket.

    I would argue that the business rule is the most significant aspect of defining business function. For example,

    PO Arrives -> Fill PO

    Regardless of how you fill the PO, you need to fill to PO to stay in business. If you fill the PO optimally, you increase profits and if you fail at this you can lose money.

    I assert that business architecture is the act of collecting and cataloging the rules that the business lives by and then looking at how they are accomplished. Hence, business rules lead business process and not the other way around.

    I would estimate that 1/2 of all companies have the wrong processes and are now using BPM to try to optimize those processes. If they would engage in capture of the appropriate business rules first, they could easily correct many of their problems without having to engage in expensive BPM activities.

    • @Michael: Does it mean that BPM deliberately degrades importance of the rules to leave a “room for improvement?? I merely meant that BPM isn't perfect. There's lots of room for improvement in the software and methods we use in BPM. Acknowledging that is just being intellectually honest. I didn't mean that as a comparison of BPM/rules per se... I think you read too much into that comment. I completely agree with your statement that rules can (should) be externalized.

      @JP - "PO Arrives -> Fill PO"
      What you wrote is an implication, I presume. It is first order predicate logic but you've missed the point of what is conceptually a rule versus what is implemented via a rules engine. All the lines in a BPM diagram could be described as rules that dictate routing. Take away that diagram. Write the rules that describe your state machine. Write them all. Is it easier to understand than the diagram?

      It isn't that rules, conceptually, aren't easy to understand. But try to describe your business *purely in terms of rules* and you'll end up with something that lacks proper abstraction for the casual user.

      In a previous life I wrote configuration software for complex things like Boeing airplanes, Central office switches, PBXs, etc. We regularly came up with heuristic configuration solutions to problems that customers said were intractable and unsolvable, because we had an engine at our disposal that gave us a better abstraction (combination of backtracking heuristic search, constraint satisfaction, resource allocation, physical space modeling, connection/network modeling, and good ole fashioned object oriented code), and because we were pretty smart. But these solutions are not anything the business could maintain for themselves. The business needs useful abstractions that actually can execute. Rules don't really do that. Completeness of a rule set is also a problem.

      I'll concede that you can describe every iota of a process as if it were a rule or set of rules.. but you can also describe everything we do as a process. Rules describe the limits, they don't describe the living!
      (and does anyone really drive the speed limit, Sir? )

      thanks for sparking the thread, JP! Now. returning to your question. why is it important to you who leads? if they both have a place in the world, and both have value, who cares? :) Use 'em both.

  • JP,
    I see your point and I agree with you. One of the task of Business Architecture is to collect , help to define and preserve business rules (and regulations) in the core of and in the relationship between of business functions and feature. Business processes, come later as just implementation of these functions/features and related business rules.

    IT has difficulties with seeing things in this way because IT faces already implemented business rules (via business processes and operations) and cannot challenge these processes, i.e. implementation, itself.

  • Michael,

    I agree with your statement that IT has difficulties because of established processes, but I also find that the biz is screaming for advice, while most IT people sit back and wait for instructions. The truth is a large population of IT people are nothing more than code hacks that have very little ability to integrate their knowledge of systems with an understanding of the business to help guide their employer/client in identifying that the processes they have in place are incongruent with their goals.

    JP

  • What a fun question.

    A one-word answer:

    Lenses.

    A longer answer:

    Many in the BPM community view rules as artefacts within processes because their perspective is the process. Ask a compliance person and they'll be focused on rules. Different stakeholders have different perspectives / lenses. IMO a critical success factor in any business improvement exercise is to grasp these multiple perspectives and attempt to integrate them in a way that doesn't alienate any of the stakeholders. You might choose to say that this is part of the responsibility of an EA team (or you might not).

    A cynical answer:

    Because the vendors selling BPM technologies are bigger than the vendors selling BRM technologies.

  • JP, picking up on your last point (it was my favorite): "The truth is a large population of IT people are nothing more than code hacks..."

    Many of the so-called rules in BPM implementations are actually put in place to ensure that the appropriate data is collected to satisfy the needs of the core system, the eventual system of record for the outcome of the process. Therefore it is really the old COBOL system that the business rules and business processes are subjugated to, because its just too expensive or risky to do anything else. Making the COBOL programs work 'right' for today's business is way more than a back office IT or system guy would consider sensible. Its much easier to bolt processes and rules around the edge and hope for the best.

    (I blogged about my experience with this IT skillset gap on a project earlier this year: http://blog.consected.com/2009/06/your-systems-group-is-reason-you.html )

    If there is a real decision to be made (not just a rule to guide a 'go here, go there' in a workflow), then this will happen where it needs to happen - strictly at a point in the process, or completely outside. At the end of the day, that old mainframe may trump all, but true decisions to be made exist separately from the process (in complex systems that assist BPM or peoples' heads), and our architectures should not forget that.

    Phil Ayres
    http://www.consected.com

    • user-pic

      Phil, I had to smile as I read your reference to COBOL because I had been thinking about the ol' Shelly & Cashman edict in Structured COBOL to avoid nested if statements. It seems some of our current batch of business rules could benefit from similar advice.

      However, the real reason I am sending this reply is in response to your final paragraph. In Smart (Enough) Systems, James Taylor and Neil Radon echo the same thought in the sub-chapter, Complementing Your IT Architecture: "You can manage and deploy process and decision changes independently. When you have long-running processes, keeping decisions separate allows you to change work in progress. ...a fixed process definition that embeds decisions is a problem because business rules and analytic models might not be current when they're evaluated. If you manage decisions separately and retrieve them when a process needs the decision, the decision is always current."

      -Joe

  • user-pic

    Does everyone share the same definition of a business rule? The Business Rules Group gives two definitions. One is from the business perspective, and one is from the information system perspective.

    http://www.businessrulesgroup.org/defnbrg.shtml

    I agree that it is a question of what lense a stakeholder uses. The stakeholders are business side managers and workers on one hand, and IT workers who support the business with applications on the other. Each of these stakeholders has a ruleset with different business rules and both pertain to Process Management.

    To answer the topic question: IMO Business Rules both lead (business perspective) AND follow (information system perspective) Process Management. One ruleset is business driven and the other is information system driven. The fun part is distinguishing between the two!

    Pierre Lefebvre

  • user-pic

    BPM is a poorly thought out approach to business automation. It is purported to be 'bigger picture approach to solutions' when in fact it is thinking in the box. It is infantile compared to the kind of thinking required for enterprise solutions. Hey, we do not even have a proper definition for what a process really is.

    And lastly, YOU CANNOT MANAGE A PROCESS. THIS IS NONSENSE. SHOW ME ONE PROCESS THAT IS A MANAGED ENTITY AND I WILL SHOW YOU WHY IT IS NOT.

  • I think part of the challenge here is the number of potential uses of business rules in a process. Rules can handle routing, escalation, assignment and many other process tasks. In this case the rules are clearly tightly coupled with and subordinate to the process. So far so good.

    But business rules can also be used to automate business decisions. These may be used by a process (that needs an activity to decide how risky a loan is, what offer to make a customer, whether this citizen is eligible for this benefit) but they are independent of it. Their change cycle, ownership, governance and more are all independent of the process. In this case the decisions neither lead nor follow - they collaborate with the processes to achieve a business result. They are peers.

    Business rules can also be used to automate decisions that respond to events, to the information available outside the organization. In this more event-centric approach the decision must come first. It will decide which processes might be needed to handle the response to the event, it will decide what the information available should cause to happen. It makes the choices that will drive the process. Decision first, process in support.

    There is also the issue of unstructured processes. In these cases the emerging consensus seems to be that one should define process fragments and then have an always-on decision that constantly evaluates the state of the case/process and triggers or assembles the right process fragments. In this case the decision is acting as an orchestrator for the process.

    I do think that many process-centric organizations and products do not manage or respect business rules but this is, in part, because they are not thinking about the business decisions they are making by following those rules.

    JT

    Author of Smart (Enough) Systems - thanks Joe
    My ebizQ Blog

  • I followed James' blog to this debate (and concur with his response), as it is quite an interesting one from many perspectives (and came up a few times at this week's Business Rules Forum 09 / RuleML09 conferences).

    1. If you follow something like the OMG Business Motivation Model, you will see that business processes are defined to execute business strategy, policy and related business rules.

    2. Business processes (however they are modeled / implemented - BPM flow diagrams, bunches-of-rules, plain-old-UML-and-code, event processing engines, etc) always embed decisions - often called business rules - and so these may be defined as a part of defining processes.

    So the answer to JPM's "Why are business rules subjugated to process management when business rules should be leading process management? " is "they do both, depending on your definition of business rule".

    Disclosure: TIBCO is both a BPM/SOA and rules+decisions tool vendor (amongst others).

    Cheers

  • I agree with you JPM and others may be interested in recent discussion on this matter on my and Jim Sinur's Gartner blogs (see links below). There are two aspects to this problem. One is that as business rules technology crossed the chasm with regard to accessibility (e.g., English and spreadsheet metaphors) it also needed to cross the chasm with regard to applicability. Decision management, as originally conceived by Fair Isaac insightfully and successfully pidgeon-holed business rules within static decisions situated in business process. The insight here was that business rules did indeed address the failure of BPM with regard to agility precisely where it was most significant (i.e., with respect to business logic).

    Decision management was successful enough to forestall any deep thinking or progress in relating reasoning technology (including rules) to process orchestration. That is, as long as the rules where insight a flowchart box, why worry about how knowledge should govern or define the flowchart itself!?

    To put this another way, the vendors have advanced the technology very little over the last five years because their focus is on the applications and broader markets of BPM, both in applications (e.g., Siebel) and middleware (e.g., IBM, SAP, Oracle, TIBCO).

    Completely rational but not very inspiring.

    Fortunately, increasing competition given recent M&A, CEP, and BMM should lead to some progress.

    http://haleyai.com/wordpress/2010/01/11/rule-and-event-driven-business-process-ma/

    http://blogs.gartner.com/jim_sinur/2010/01/20/rule-representation-the-potential-showdown/

  • Fun discussion. My 2 cents. . .

    Business rules are subjugated to process management because rules are logically subordinate to processes. You can remove the rule from the process but you can't remove the process from the rule. Take away the speed limit (please!) and I can still drive to grandma's house, but remove my need to use a car and speed limits cease to have relevance to me.

    Rules require a process context in order to be useful. They are important in governing the execution of a process, but the process must exist first.

    • user-pic

      Hi Marc, I quite like that example. However, could you not view, in a less abstract way, the process of intending to drive to gradma as a rule? For example: If you want to make grandma happy, drive to her (and if you drive, stick with the speed limit.)

      So, a process is merely "a certain way to look at a group of rules, explicitly and implicitly", to quote Olaf Resch above.

  • Marc, how very true. But you need to follow this train of thought through.

    If you remove PEOPLE from the equation you don't need cars, no roads and speed limits.

    So in all process or rule thinking it is PEOPLE who come first. Processes and rules MUST NOT subdue or control people, but support them. That is the biggest problem with BPM and with rule engines today. Actually with most software solutions ... except maybe Social Media, who a need a few rules, a little process and a link to business entities as otherwise they just have conversations, but not about business.

    PEOPLE first and keep them there all the way!

  • Wow, what for a long going discussion :)

    A process is a certain way to look at a group of rules, explicitly and implicitly, e. g to place a function A after a function B in a process diagram is an incarnation of the rule: function B must follow function A. In the previous discussion a lot of advantages of the processes form of presentation were already named, e.g. it is a very tidy way to look at the world...first this...then this...and then that. However, it can at least be presumed that this tidiness is sometimes an end in itself and does not always models the real world. This fact becomes more important, when the world is not fully determinable and this is increasingly the case. A sophisticated business rule management system would accept a process as a form of presentation but decompose it into the underlying rules. This would allow to administer these rules along other rules which did incarnate in other forms, e.g. if-then-syntax and to switch between different forms of presentation. Presentation of rules and rules are different matters. If you are interested in this topic you also might find our workshop summary paper interesting. http://www.e-journal-of-pbr.info/resch-six-views-business-rule-management-system Please let me know your thoughts.

  • I followed James' blog to this debate (and concur with his response), as it is quite an interesting one from many perspectives (and came up a few times at this week's Business Rules Forum 09 / RuleML09 conferences).

    1. If you follow something like the OMG Business Motivation Model, you will see that business processes are defined to execute business strategy, policy and related business rules.

    2. Business processes (however they are modeled / implemented - BPM flow diagrams, bunches-of-rules, plain-old-UML-and-code, event processing engines, etc) always embed decisions - often called business rules - and so these may be defined as a part of defining processes.

    So the answer to JPM's "Why are business rules subjugated to process management when business rules should be leading process management? " is "they do both, depending on your definition of business rule".

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT