Introduction and Principles

Welcome to my first posting on the DRA blog.  I hope you find it interesting and useful.  I am planning to publish these ideas soon in a book, but first I wanted to share them with you - colleagues, friends and anyone with a common interest - and collect your feedback.  Please feel free to comment, criticize or argue, and to contribute your own ideas.

I have been building rule-based systems now for over twenty-five years, and in my experience the most difficult problems with rules projects are rarely technical;  they are to do with management and communication.  For example:

• How can you discuss the required decisioning at a high level with the client?
• How can you define the scope clearly at the outset of the project, before any rules have been collected? 
• How can you implement the project in stages without the need for extensive rework?
• How can you avoid nasty surprises half-way through (e.g. the need to integrate with an extra source of data)
• How can you divide the development tasks between multiple teams or locations and be sure the components will integrate properly?
• How do you know when you've finished?

Decision Requirements Analysis (DRA) is the approach I have developed as a response to these problems. 
It has been adopted by FICO as a standard part of our FIRUP methodology, and is now being applied by some of our clients, so I'm hoping there is a large enough user base to make these discussions interesting.  DRA is a formal method comprising:

• The Decision Requirements Diagram (DRD):  a new type of diagram showing the structure of the required decisioning as a network of decisions and sub-decisions with their supporting areas of business knowledge and data
• A structured workshop technique (DRAW) allowing a methodical top-down analysis of a decision into the structure recorded in the DRD and supporting documents
• Best practice guidelines on the use of DRA in project planning, rules discovery, functional design and system development.

My plan is to introduce these components one at a time, in separate postings, to allow discussion of each before moving on.  This first posting is just to set the scene and declare some initial tenets.

The underlying principles of DRA are simple.

Deliver the requirement, and nothing but the requirement.

The success of any development project depends on being able to contain the scope and deliver the agreed requirement. The basic principles of sound project management are well understood. Unfortunately, rules projects are notorious for scope creep, often caused by vague requirements.

We must not allow rules projects to be treated as an exception, just because they are difficult. Where the business logic to be implemented is very complex it is even more important that the functional requirement is clearly stated and agreed by the client. This is not incompatible with iterative development, as I will show. Misunderstandings over scope at the outset of a project can be catastrophic for both supplier and client.

Always work top-down, not bottom-up.

There is a tendency to think that business rules can be randomly “harvested” from an organisation, and can then be assembled into useful repositories. There are many problems with this approach, chiefly:

• An organisation may have millions of business rules, and only a small fraction of them will ever need to be represented in a rule service
• A single logical fact may need to be expressed as several different rules for use in different decision-making contexts.

Besides, just collecting and modelling existing business rules is anthropology, not Decision Management. Our goal is to change decision-making in the organisation, and the only viable approach is top-down: define the desired business decision, then design and develop the rule service to implement it.

Rule services make decisions.

A rule service is fundamentally a decision-making component. So, although it can be specified in various ways (e.g. as an algorithm or an input-output mapping), the best way to define its functionality is purely in terms of the decisions it makes.  Each decision can be defined as a means of providing an answer to a question. So if you can clearly define the questions, the answers, and the means, you have completely defined the functionality of the rule service.

Decisions require information.

You can discover the requirements of a decision by asking what information is required to make the decision.  Information is of three kinds:

• Business knowledge (in all its forms:  rules, calculations, analytic models etc)
• Data describing the case to be decided on
• The results of other decisions.

The last point is the key:  this allows decisions to be decomposed into a network which can be drawn in a Decision Requirements Diagram (DRD).