Skip to Content

Introduction

One of the most common mistakes that developers and architects of software systems make is to mistakenly assume that the Business Rules in their Applications are a part of the Software Requirements. As a result, Business Rules are treated and managed like Software Requirements. Nothing can be further from the truth. We argue why this is an incorrect approach, and go ahead to suggest a better and more agile method for managing Business Rules.

Software Requirements & Business Rules– A Definition

So, what are Software Requirements? To quote from Wikipedia,

  • Software Requirements  describe the Behavior of a software System to be developed
  • Software Requirements include sets of use cases that describe all the interactions that users have with Software
  • Software Requirements include non-functional requirements like quality, performance, design constraints and so on

Developers and Architects use these requirements as inputs to their design and development activities.

Business Rules on the other hand describe or represent constraints on the behavior of the business. Business rules represent the core business logic of each organization; they guide and control the basic business processes that form the back bone of any business transaction

When working with business rules developers have to take into consideration that such rules are inherent in:

  •  Corporate charters
  •  Management practices and regulatory forces
  •  Human resources management
  •  Marketing strategies
  •  Pricing policies
  •  Products and services offerings
  •  Customer relationship practices

Business rules are the most dynamic component of any application. Therefore their constant and correct identification and externalization improve the organization’s adaptability to industry changes and competition.

For a more detailed introduction on the subject of Business Rules, please refer Getting Started with Business Rules management.


Read more to learn about the Rules Vs Requirements Paradox

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Jurgen Lootens
    What are you suggesting people should do differently? Can you give some concrete examples? You’re a bit vague… or are you leaving us hanging for blog number 4, 5 and 6?

    And some IT departments do understand their business’ rules. Just so you know.

    (0) 
    1. Michael Nicholls
      How ever the business rules are defined, they still need to be processed by the application. Yes, they can more dynamic, but they still need to go through the same software lifecycle (definition -> design -> build -> test etc), so in some ways it is acadmeic to separate the two.

      Whether they are defined as code or through some other meta markup, is immaterial.

      (0) 
      1. Ramesh Ramaswamy
        Hi,
        The business rules dictate the way the processes should be performed.The processes themselves are subject to change;so does the rules.
        The application supports these rules.As these rules are run thro’the system they go thro’the life cycle as applicable to any other development.
        (0) 
  2. Anonymous
    So, here is how it is.

    @Jurgen
    Lets take the example of determining eligibility for say a personal loan.

    The Requirement is that the System should enable the Business User to make this Determination

    The Business Rules will provide the basis for making this determination.

    Example of Business Rules used for Income Validation
    ——————————————————

    See this image through this link of a Decision Table modeled in QuickRules, the BRM SAP acquired from YASU Technologies in Oct 2007.

    http://api.photoshop.com/home_3e212ee5218544eb8cbbc8d8e2ea81fa/adobe-px-assets/b30cd4b8f6624922a48d8d86cd21de7b

    The Decision Table in the above image checks other income conditions like city category and minimum expected income , Income Deviation percentage

    The Paradox here is this.
    ————————–
    1. If you treat rules as requirements then IT are responsible for the business rules also
    2. But rules are owned by the Business, therefore IT cannot be responsible for the correctness of business rules

    Why You should handle rules separately
    ————————————–
    1. In our example here, the rules will change often
    2. Expert Business Users will be required to make correct changes to these rules
    3. Modeling Such rules is a COmplex Affair
    4. When you use Business Rules, you design for change

    @Ramesh, I agree with you , but there is more to rules than just routing
    Rules that dictate processes are essentially routing rules, and that is just one of the ways to use rules

    But the bigger value if through the clear separation of decisioning logic from process/application logic.

    Also, I agree that rules also have a similar lifecycle, but the lifecycle of rules typically runs in parallel to the application lifecycle. This is because (externalized) business rules typically tend to change faster than the rest of the application.

    (0) 
    1. Michael Nicholls
      So, the requirement for all programs is to support the rules!

      The rules must still refer to details that are known to the programs, which means there is still a tight coupling between program and rules.

      I see a tool like you describe as being more useful as a design tool, which can be used to describe what the business wants, rather than a ATFAP (all things for all people) runtime tool, as there will often be the need to perform optimization and data integrity checks before neing rolled out to the real world. Yes, business people know what their business does, but they shouldn’t be responsible for providing optimized run time applications.

      (0) 
      1. Anonymous
        Hi Michael,

        You are correct and I agree.But there is More to it than meets the eye.
        With Business Rules as with any other technology, we take a evolutionary approach towards maturity.

        “Early Stage”
        Our goal is to Externalize critical rules from the application so that they can be managed by IT. In this stage, the benefit will be flexible & configurable applications

        “Next Stage”
        Business Users participate in the change management process and edit business rules. This is possible because of the tools provided by Business Rules Technology. For examples, Decision Tables are simple, but very powerful tabular representations and appeal to business types.

        “Evolutionary Stage”
        Business Users Manage “Business Rules, and IT will handle those rules that wire up the business rules into a logical execution unit for the rule engine.

        Conclusions
        ———–
        1. Business People are responsible for Correcteness of Business Rules
        2. IT are responsible for Implementation of Applications
        3. BRM enables tighter participation of Business People into the Change Management Process by Providing Visibility and Eventually Control of Business Specific content(Rules) used by Applications

        (0) 

Leave a Reply