Modelling Rules

veryard projects - innovation for demanding change

modelling rules

veryard projects > modelling > rule modelling

we offer

scope

available material

links

education, training and skills transfer

model reviews

information and advice on methods and tools

supporting materials - including patterns

Business rule modelling provides a view of the rules, policies, regulations and other constraints imposed on the business. This includes structural constraints as well as process/sequence constraints, and gives us (among other things) a view on workflow, workload and work control.

We use a general notion of rule, that includes related concepts such as constraint. This notion can apply at any level: to a method/operation, to a whole component, or to a whole system. This means we need ways of understanding rules to allow for composition and decomposition. In particular, we may want to encapsulate rules - designing a set of software components each scoped around a single well-formulated rule - and then reason about the global behaviour of the assembled systems.

Rule Diagram

What is rule modelling good for?

Models and Monsters - The Exception "Proves" the Rule

Declarative and Procedural Specification (What not How)

Rule Model Diagram

veryard projects > modelling > rule modelling > diagram

The rule diagram helps to specify the logic of collaborations, processes or operations. It offers a user-friendly notation for first-order predicate logic. It can therefore be used to show:

the invariants of a collaboration or process,
the preconditions for a process or operation,
the postconditions of an operation.

how good is rule modelling?
(what is rule modelling good for?)

objectives / benefits
	Business Understanding	Business rule modelling provides a view of the rules, policies, regulations and other constraints imposed on the business. This includes structural constraints as well as process/sequence constraints, and gives us (among other things) a view on workflow, workload and work control.
	Flexible Design	If system design is based on a rule architecture, then we should expect the following benefits: Adaptability - ease of changing rules - requisite variety Transparency - easier to perceive the motivation of a given element or aspect of the system - "why is this here?"
	Upward Rationalization	Improve the structure and behaviour of systems by introducing or strengthening useful rules. Maintain requisite variety. Reduce unnecessary variation. Reduce fraud, moral hazard, anxiety.
	Downward Rationalization	Improve the structure and behaviour of systems by eliminating bad or redundant rules. Increase flexibility / autonomy / requisite variety. Increase efficiency / effectiveness.
	System Understanding	Make informed judgements about system structure and behaviour. Reason intelligently and reliably about the effects of ruleset changes.
	System Inference	Business rule modelling can be carried out on a blackbox system - simply by observing the (external) behaviour of a system or organization, we can infer the rules by which it is governed. This means that it is useful as a way of reasoning about the potential behaviour of customers and competitors under various conditions. It also means we can reason about the emergent properties of complex systems without knowing the detailed structures and mechanisms of the components and services from which the systems are assembled.

arguments for arguments against

Expressing requirements in the form of rules is a Good Thing, because it abstracts away from the mechanism, and is therefore more flexible.

Rule modelling creates the potential for automated reasoning about the interactions between rules.

So if rule modelling is such a good thing, why isn't it more widely practised?

People don't naturally think in terms of abstract rules. Rule models are therefore difficult for most people to understand.

Rule modelling notations don't scale easily.

We believe that tools will go some way to address these concerns. However, there is currently a shortage of good modelling tools in this area. We deplore this situation, and we are seeking to redress it.

reasoning with rules

Here are some of the ways we want to reason about systems, rules, and the interactions between rules. Formal notations and rule models create the possibility of automated or semi-automated reasoning - in other words, getting the tools to do some of the work for us. Such automation (if done properly) will greatly alleviate the problems of complexity and scaleability experienced with informal and manual methods of rule modelling and analysis.

	Modelling	Given a system (organization, human, computer or hybrid), produce a set of rules that explains the behaviour of the system. The behaviour of the system should conform to the rules. The rules should predict the future behaviour of the system, under a range of conditions. The rule model (or ruleset) can be regarded as a theory about the behaviour of a system. Note: we can carry out this modelling even when we have no access to the internal structures and mechanisms of the system - the blackbox scenario.
	Testing	Given a system and a set of rules, test whether the behaviour of the system (regarded as a blackbox) conforms to the rules.
	Requirements	Specify a desired behaviour pattern, or a desired change to an existing behaviour pattern, as a set of rules.
	Implementation	Design something to implement a ruleset or ruleset change. (This may be a software artefact, a work practice, or a hybrid sociotechnical system.)
	Verification	Predict the interaction between multiple rulesets. Predict the interaction between multiple systems and components Predict the side-effects of a given implementation. Confirm that a given ruleset, in a given context, will generate the required behaviour. Reason about the aggregate / ecological effect of imposing / enforcing a given ruleset.
	Exploration	Analysing a system and its rules to find improvement opportunities. Find degrees of freedom / flexibility that are possible / permitted but not exercised. Find "rules" within the behaviour of a system that can be traced to habit rather than edict or reasoned choice.

Flexibility as the Absence of Rules

veryard projects > modelling > rule modelling > flexibility

Flexibility, requisite variety and autonomy may be regarded as a partial absence of rules.

For example, a bespoke application program may be written on the assumption that all amounts of money are in US dollars, and all dates are in US format. These can be regarded as rules embedded in the program, which constrain the possible use of the program in Europe or elsewhere. In contrast, an application package may be written without these rules, allowing for any currency and a wide range of date formats.

It is often more difficult to spot the absence of rules than the presence of rules.

When considering the acqusition and implementation of large application packages such as SAP, PeopleSoft and Baan, you need to take a view both on the constraints (rules) built into the package, but also the degrees of freedom (absence of rules).

For every degree of freedom, for every absent rule, there is the possibility of a choice. This choice may be exercised in many different ways - perhaps at design time by the implementors, perhaps at run-time by the users, or perhaps by a separate software component containing a decision algorithm.

The Nature and Nurture of Flexibility

rule structure

We separate the basic rule from extensions, exemptions and enforcement rules.

Basic Rule - on this road, maximum permitted speed = 90 kph

Extension - private aeroplane crash-lands on road, triggering speed camera - does this rule apply in this case?

Exemption / Exception - police, doctors, priests (subject to role)

Enforcement - speed camera, fine

We often want to add or change extensions, exemptions and enforcement rules.

And we often want to analyse the aggregate or ecological effect of a subsidiary rule. For example, consider the following rule enforcement exemption (don't pursue foreign cars).

What are the consequences of this rule enforcement exemption (don't pursue foreign cars)?

short-term benefits

avoid excessive enforcement costs

no need for integration with foreign systems

longer-term costs & risks

enforcement exemption becomes public knowledge (becomes de facto rule exemption)

tourists drive fast with impunity

local residents acquire foreign reg cars

local resentment against foreigners / foreign cars

Among other things, this analysis indicates that a rule enforcement exemption should not always be reduced to a rule exemption.

representing rules

In some approaches, rules are represented as something else. For example as data objects or state transitions. Or they may be inferred indirectly from the structure of an information model or process model.

Translate rules into data objects?

For example, rules that govern objects can be represented as further objects. With relational data models, rules can be represented as entity types.

Many structured methods for relational database (such as Information Engineering) allow you to have derived attributes. I thought it would be good to have derived entity types and relationships as well. I published a paper about this in Information and Software Technology over ten years ago (when Information Engineering was still fashionable), and this paper became Chapter 5 of my book on Information Modelling.

Given that relational databases with raw SQL supported a wide range of derived tables (although the performance wasn't always brilliant), I always thought it was a pity that some CASE tools and structured methods didn't take advantage of this.

My main concern then was that the rules should remain the same even when the data change. (I was always sceptical of the presumption that data changed less frequently than business process.)

Retail example

For example, in a retail situation, you might have a reordering rule based on a stock estimate. If you implement Electronic Point of Sale (EPOS), you can replace the stock estimate with a much more accurate and up-to-date stock figure, based on actual sales data. But from a business point of view, the reordering rule itself remains the same. To get this flexibility, we need to decouple the reordering rule from the stock estimation rule (derivation algorithm). If the reordering rule merely references a data object called STOCK, then all I have to do is plug in a different stock calculation algorithm, and the reordering rule remains the same.

This approach has to be carefully qualified. I came across the following example recently in a supermarket chain. In the old system, the stock figures presented to the store manager in the morning were based on yesterday's figures, with an adjustment for any expected overnight deliveries. But of course sometimes the expected overnight deliveries didn't turn up, and so the figures would be wrong. In the new system, overnight deliveries would be recorded into the database immediately. Stock reports would be printed off at midnight ready for the following morning, and would accurately include all deliveries made before midnight. So therefore the store manager would have more accurate stock data. Or would he?

What about deliveries scheduled after midnight? What about deliveries arriving after midnight (especially those scheduled for delivery before midnight)? Interviewing the IT project manager, I got a strong impression that these questions had not been properly thought through.

Of course the midnight printout process is a naff one, and we can think of various ways of fixing it. What interests me most in the midnight printout example, is the nature of the error in thinking that led to this naff process. This supermarket chain was spending a large amount of money on implementing this naff process - not just the IT development and equipment costs, but the change management costs as well. As far as I could tell, there was a genuinely held belief that this was worth doing, because it made the data more accurate. And there was a cost-benefit argument supporting this - I didn't ever see it, but I know it existed. My hunch is that there was a particular kind of data-oriented thinking, together with a particular notion of data accuracy, which led to this error.

Among other things, I'm looking for a good way of reasoning about such situations. I'm not convinced that a data-oriented approach forces analysts to ask all the right questions, in a systematic way. I believe that an explicit rule analysis would have helped the analysts avoid this naff process.

Translate rules into state transitions?

One way of looking at this kind of problem is that we have rules ABOUT rules, or perhaps rules ABOUT data. Thus STOCK = (IF delivery-schedule < midnight THEN STOCK-RULE-P ELSE STOCK-RULE-Q). In some cases we may be able to translate this kind of rule into state transitions, but I'm not sure how useful or generally applicable this is.

Note that in this case, the condition is determinate. Either the delivery schedule is before midnight or it's not. We could therefore represent midnight as a state transition, if we wanted to. But sometimes we use conditions that cannot be determined in advance. This is especially true in open distributed systems.

For example, an application needs to carry out an Internet search. We may put out multiple enquiries in parallel, and respond to whatever responses we get. Thus SEARCH-RESULT = (YAHOO-SEARCH and LYCOS-SEARCH and ALTAVISTA-SEARCH and ... and ...) On a particular occasion, some of the search engines may not yield a response within a specified time.

But we don't know this in advance. This is why we cannot code this as SEARCH-RESULT = (IF yahoo is quick today THEN YAHOO-SEARCH else LYCOS-SEARCH.)

top

home page

in asssociation with