The Community Blog for Business Analysts

Dr David Fletcher
Dr David Fletcher

Business rules are a backward step

I have been delivering projects successfully since the early 80s. Back then, we didn't have business rules, we had formal logical data models, entity life histories, data constraints, and data flow diagrams. In general, all the necessary business constraints got captured properly and implemented. Some of these deliveries actually passed acceptance testing with no defects.

Since then I have joined a company which does use-case driven development, and in the use cases there is a section for 'Business Rules'. Logical data modelling is rarely done, and life-history modelling is almost never done. Business constraints are now frequently missed and contradictions are not detected or poorly understood. Having read many hundreds of such rules by now, I conclude that they mostly consist of data constraints which ought to be in a data model, event processing constraints which ought to be in an entity life history, or security and audit constraints which might actually legitimately belong in a rules catalogue (the latter are the rarest category).

From this I conclude that the concept of a business rule is too vague, and business rules are often  an excuse to avoid doing thorough modelling. As Ivar Jacobsen once said 'if you have not modelled it, you have not understood the problem".

This entry was published on May 13, 2011 / Dr David Fletcher. Posted in Business Rules. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  4 members liked this article

Related Articles

COMMENTS

Putcha posted on Monday, May 16, 2011 9:57 AM
Good points. Yes, they have to be taken care of even now but differently.

The focus of each use case is the "Business Service Goal and dialog (exchange of messages and data between the system and actor) necessary to reach it".

The business rules exist in the form of policies and conditions / actions / exceptions affecting setting up and operation of businesses. Some rules are external in the form of laws and regulations. Some are within the purview of the business organization. They have to be captured from organizational documentation / managers and applied to various UML Diagrams. The basic logic is the same as what was used in earlier methodologies and conventions.

The rules may be captured at inception and through ongoing interactions with identified actors. Then they should propagate to class diagrams, sequence diagrams and their contents (attributes, operations, messages etc).

I have felt a need to create an actor “Business Manager” to present the policies and rules to the system which contains an “internal rules repository & supplier”. Ideally rules should NOT be hardcoded into software but should flow from business manager as parameters and limits into objects. Business Rules Community (brcommunity.com) has well evolved methods to handles this.

[email protected]
Putcha
Dr David Fletcher posted on Friday, May 20, 2011 4:11 AM
Thanks for that. Might I ask then what is the form of a policy, a condition, an action, or an exception, if you were to write each of them down?

Would they all have clearly distinguishable forms of expression, such that one could look at a statement, and know immediately which one it was, or that it was clearly none of them?
Dr David Fletcher
Putcha posted on Friday, May 20, 2011 6:37 AM
Dear David Fletcher:

From ISO 9000:2005 definition of quality policy I take that policy on any subject is “Overall intentions and direction of an organization related to ABC as formally expressed by top management”. I consider this captures and presents the meaning and scope of “policy” precisely compared to dictionary meanings which spread out the scope and talk of other factors / parameters (decisions, actions and other matters) which are related to policy but not a part of it. “guiding principle” is also acceptable as the meaning of “policy”.


ISO 9001:2008 Quality Management System --- Requirements spells out how a policy, in this case ‘quality policy’, is defined and implemented. See sections 5.3, 5.4 and 5.5 and their subsections for one possible structure and content of a policy. It is possible that there are other sources which may deal with structure and content of a policy & its implementation but I found ISO 9001 well-developed and adoptable.

Policies, rules, and procedures are expressed in natural language text with some structure for humans to read / implement / manage.

It has to be more structured and precise (structured text or mini spec) for computerization or automation. Categories, conditions, exceptions, decisions and actions presented in the form of tables or spreadsheets (Ultimus1) serve as good examples. I also use predicate calculus and enhanced RDF for this purpose. I understand that ‘brcommunity.com’ has more information on the structure and content. I have not studied them yet.

As I said I am recommending Business Manager as default Actor of every “Business System” and “Business Rules Repository” in text and tabular form or enhanced RDF to define / manage any business automation system.

I note that you have observed some problems with “business rules”. I wish to understand the problems since I see the aforesaid structure and procedures actually use business rules to bring order to business automation. Let’s explore.

Best wishes,

[email protected] 20MAY11
Putcha
Seo Keo posted on Saturday, October 15, 2011 8:19 PM
Just a small remark on the topic: business rules had existed long before 80's. Any business adheres to them. All models are just a reflection of these rules.

Cheers,

Seo
Seo Keo
Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN

 



Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.

 




Copyright 2006-2024 by Modern Analyst Media LLC