How to Create Effective Business Rules: Interview with Graham Witt
When tackling Data Quality you need to understand and manage the thousands of business rules that can exist across your organisation.
To help you understand some of the core methods involved we asked Graham Witt, author of "Writing Effective Business Rules", to share a range of practical tips and techniques to learn this vital skill.
Dylan Jones: In 2012 you released a new book titled “Writing Effective Business Rules”. What are some of the key themes of this book and what sets your particular approach apart from others in the field?
Graham Witt: Every organisation operates according to rules so as to minimise risk, reduce costs, and protect revenue. If an employee, customer, or partner of that organisation fails to comply with one of those rules, the outcome may range from financial loss to serious injury or death. Compliance is more likely if all employees, customers, and partners can establish what rules apply in each circumstance.
This is best achieved if each rule is documented in a clear, unambiguous, and accessible statement in a natural language (as distinct from a programming language) used by the organisation (such as English or French) using terminology that all community members (not only systems developers) understand. This has the added advantage that stakeholders can more easily review rules for relevance and correctness, approve them, change them as required, and so on.
Unfortunately rules may be documented in different ways, indeed some may only exist as program code, as database constraints defined in DDL, or as rules engine instructions.
Natural language rules, if properly written, are intelligible to all business stakeholders. However natural language has two disadvantages. The first is it can be ambiguous: some natural language statements can be interpreted in more than one way. The second disadvantage is that a given rule can be expressed in many different ways using natural language. As a result, similar rules can end up being expressed using quite different rule statements, which makes the detection of duplicate or conflicting rules more difficult.
The answer is a constrained natural language, a subset of a natural language in which both syntax (sentence structure) and vocabulary are limited – much as the language used in international air traffic control communication is a constrained version of English.
The approach taken in my book is to firstly itemise the various types of rule that may govern an organisation then describe the best sentence forms to use for statements of each type of rule.
This is not unique: Terry Halpin, Ron Ross and Tony Morgan have all produced similar work. What distinguishes my approach from that of Ross and Morgan is that I have been rather more prescriptive about what sentence patterns to use for each type of rule statement. On the other hand Halpin has been similarly prescriptive but has focussed on data rules. The more prescriptive approach means that any two rules of the same type will be expressed using statements having the same syntax, which can more easily be compared to ensure that they do not duplicate or conflict with each other.
Other aspects of rule documentation that I’ve focussed on in rather more detail than other authors are:
making a distinction between:
objects in the physical, legislative and regulatory environment in which the organisation operates
constructs by which the organisation envisions various aspects of their business (such as organisational concepts, categorisation schemes, measurements and calculations)
the data that it captures to represent those objects and constructs
(given that it has become unfashionable in the English-speaking world to teach grammar) a summary of the different types of word, phrase and clause that can appear in a rule statement and how they can be used to form grammatically correct statements
a comprehensive description of a structured business vocabulary (aka fact model, verb concept model) in which the organisation should collect the terms it uses to describe its operations and the verb phrases it uses to relate those terms, as well as a guide to building such a model
a comprehensive guide to writing quality natural language rule statements, as well as a set of meaningful quality criteria against which they can be tested
an end-to-end rule management methodology, covering discovery, analysis, vocabulary development, documentation, quality assurance, publication, and ongoing maintenance
a comprehensive set of templates (patterns) to guide rule statement authoring.
Dylan Jones: A common question I see appearing on forums is what are the differences between a data rule and a business rule. Can you help our readers clarify the difference?
Graham Witt: Of course the difference depends on your preferred definitions for the terms ‘data rule’ and ‘business rule’, of which there have been many. My preference for ‘business rule’ is the Barbara Von Halle definition: “a condition that govern[s] … business event[s] so that [they] occur in such a way that is acceptable to the business.” Meanwhile the McGraw Hill Science and Technology Dictionary definition of ‘data rule’ is “condition which must be met by data to be processed by a computer program” (although the term is also used in data profiling which usually occurs after the data has been processed).
A data rule is therefore merely one category of business rule, the other major categories being activity rules (which govern the execution of business processes or other activities without reference to any data) and party rules (which make distinctions between different parties or roles in terms of permissions or restrictions).
Activity rules may:
confine an activity (such as online check in for a flight) to a particular time period
prohibit an activity (such as operation of electronic devices in flight) from occurring during particular time period
prohibit an activity (such as boarding a flight) unless some other activity or event has previously occurred or some pre-requisite condition exists
prohibit an activity if some event or other process has previously occurred or some dangerous or illegal condition exists
restrict the simultaneous occurrence of multiple activities
define the minimum period for which a particular type of information is retained (i.e. prohibit deletion of information during a particular time period)
require an activity to occur either within a maximum time after a particular event (such as the completion of some other process) or when particular conditions apply
determine what action a business process or device is to take in specific situations.
Party rules may:
place restrictions on who can perform an activity or play a role, based on age, some other physical characteristic or capability, or training, testing, and certification in the appropriate skills
prohibit the same party from performing two activities
require that the party performing the second of two activities must be the same as the party who performed the first of those activities
define who can view, create or update particular information
define who is responsible for performing a particular process or liable for a particular fee, duty or tax.
Dylan Jones: Where do organisations typically go wrong with business rule creation? What are some of the most common mistakes you’ve witnessed recently?
Graham Witt: Perhaps the most common mistake is to fail to take into account all the ways in which a user interface can be misused, and thus allow data into a system that is obviously wrong or even meaningless.
One feature of my approach is a rigorous analysis of the constraints that should apply to data input via a user interface: for each input form, consider each field in turn and ask:
Is this field mandatory, i.e., must it be filled in on every occasion? If not, what are the occasions when it must be filled in – alternatively what are the occasions when it may be left empty?
What are the constraints on the values that may be entered into the field?
Must it be a value from some set?
Must it match some other value exactly?
Is there a range outside which it must not fall?
Must it be different from other values of the same field, either on the same form or in existing data?
Are there other data items with which it must be consistent in some way?
Perhaps the second most common mistake is to write ambiguous rule statements (that can be interpreted in more than one way). There are numerous sources of ambiguity in natural language: for example
‘it’ in a sentence with more than one preceding term could refer to either of those terms, as in “Each flight booking that specifies an origin city outside Australia and a destination city within Australia must specify whether it is the city of residence of each passenger”
failure to adequately qualify a term so as to identify the instance that the author means to refer to: for example, “Each application for life insurance must specify the birth date” doesn’t make clear whether it is the birth date of the life insured or the beneficiary that is required
using the same term more than once can lead to ambiguity: for example, in “A party who acts on behalf of another party must be cited by the party in an Authorisation to Transact” it is not clear which of the first two parties is being referred to by the third use of the term ‘party’
including both ‘and’ and ‘or’ in a qualifying or conditional clause may lead to ambiguity, as in “An applicant must hold an Australian passport or a business skills visa and an Australian state driving licence”
a qualifying clause that includes both ‘that’ and ‘and’ (or ‘that’ and ‘or’) may be ambiguous: for example, “a car that belongs to a person that lives in Sydney and that is white”
a predicate containing ‘at least’ and ‘less than’ or ‘fewer than’ is ambiguous: for example does a quantity that is 3 fewer than the number of passengers comply with the predicate “at least 2 fewer than the number of passengers”?
Dylan Jones: The majority of our members are obviously interested in data quality improvement. How can an effective business rule development process improve data quality?
Graham Witt: Rules cannot ensure that the data recorded by an organisation correctly represents the real-world objects and events that that data purports to represent, unless they are collected “before the event” and then constrain the event (such as an airline ticket). However data rules can ensure that the data is complete, meaningful, and plausible. The most obvious data rule type is the mandatory data item rule that can be used to ensure that all required data items are supplied.
Other data rules include:
those requiring that a data item contain one of a particular set of values, e.g., in an online shopping system, each order line must specify one of the product codes in the product catalogue and must specify one of the acceptable methods of payment
those requiring that a data item contain a value within a particular range, e.g., in an online shopping system, each basket item must specify an order quantity of at least 1
those requiring that two or more data items contain different values, e.g., in a flight booking request, the origin and destination cities must be different
those requiring that the instances of a data item all contain different values, either already recorded or being entered at the same time, e.g. in an HR system, a new allowance for an existing employee must be of a type that is not only different to all other existing allowances for that employee but different to all other new allowances being added at the same time
those requiring that multiple data items be consistent with each other in that:
they have a particular relationship to each other, e.g., the end date of a period of leave must be no earlier than the start date of that period of leave
they form a valid combination, e.g., in a postal address, the place name, state and postal code must be a valid combination
one set of data items is identical to another, e.g., the set of vendors specified in some real estate transactions must be identical to the current set of registered proprietors
those imposing a constraint on a set function over the values in a set of data items, e.g., the sum of the shares held by the proprietors of a parcel of real property must equal 1
Obviously such data rules will go a long way to improving the quality of captured data.
Dylan Jones: Can you give our readers a simple example of how you would create a business rule following your method so that they can see the value in your approach?
Graham Witt: While the rule statement template(s) for each rule type provide a formal pattern for statements of rules of that type, even an experienced rule author will likely use a template only to check the syntax of their rule statements. Just as, back in the day, no-one ever wrote an original Cobol program but cloned another and replaced the content as appropriate, the best approach, certainly for an experienced rule author, is to:
establish what type of rule is required
look at examples of rule statements of the required type
substitute the appropriate terms
discard any qualifying or conditional clauses not needed
Consider an employee leave application form containing fields for employee number, start and end dates, leave type, radio buttons to indicate leave with and without pay, and a checkbox to indicate that the employee has a medical certificate to cover sick leave. Each of the fields is mandatory and so requires a mandatory data item rule. A taxonomy of rules is provided in Chapter 4 of my book, including example statements for each type of rule: the first mandatory data item rule statement there is:
Each flight booking request must specify exactly one departure date.
Substitute the appropriate terms and you get:
Each employee leave application must specify exactly one employee number.
Each employee leave application must specify exactly one leave start date.
Each employee leave application must specify exactly one leave end date.
Similarly the leave type entered must be one of the leave types allowed by the organisation: this requires a value set rule, of which there are two examples in the taxonomy of rules:
The travel class specified in each flight booking request must be ‘first class’, ‘business class’, or ‘economy class’.
The origin city specified in each flight booking request must be one of the cities served by the airline.
You have a choice here, depending on whether you want to “lock in” the leave types.
Substitute the appropriate terms and you get:
The leave type specified in each employee leave application must be ‘annual leave’, ‘sick leave’, ‘leave without pay’, or ‘maternity leave’.
The leave type specified in each employee leave application must be one of the leave types allowed by the organisation.
Dylan Jones: Finally, I noticed that “Writing Effective Business Rules” provides “...a user guide to the SBVR specification...” - what is SBVR and why should our members take an interest in this?
Graham Witt: The SBVR (Semantics of Business Vocabulary and Business Rules) is an OMG (Object Management Group) standard setting out the meta-rules for documenting a business’s vocabulary and rules.
It is heavy going for the average practitioner as it doesn’t so much define a single language for expression of rules as set out the rules that such a language should comply with – indeed it refers to 3 constrained natural languages: Ross’s RuleSpeak®, Halpin’s ORM (Object Role Modelling) verbalisations and an SBVR Structured English.
While there are resources in which a full specification of Ross’s and Halpin’s languages can be found, the same is not yet true (as far as I know) for SBVR Structured English. It is certainly not fully specified in the SBVR.
About the Interviewee - Graham Witt
Graham Witt has over 30 years' experience in assisting organisations to acquire relevant and effective IT solutions.
Graham has developed specialist expertise in business requirements, architectures, information management, user interface design, data modelling, relational database design, data quality, business rules, and the use of metadata repositories & CASE tools. He has also provided data modelling, database design, and business rules training to various clients including NAB, Telstra, British Columbia Government, and ASIC and in the form of public courses run by Ajilon and Simsion Bowles and Associates (Australia) and DebTech (USA).
He is the co-author, with Graeme Simsion, of the widely-used textbook "Data Modeling Essentials" and is the author of the newly published book, "Writing Effective Business Rules" (published by Elsevier). Graham has presented at conferences in Australia, the US, the UK, and France. He writes articles on natural language business rule statement development for the Business Rule Community.
Visit his company’s website at www.ajilon.com.au or contact him at graham.witt@ajilon.com.au
Graham is one of the industry’s most experienced Business Rule experts