Computerworld has an article of interest to DNC/ADS modelers by Ronald G. Ross called "Business Rules Connect First". It is an extract from his new book Principles of the Business Rules Approach in which he describes Business-driven Development as the notion that the business owners set the agenda for development and stear (control) it through the definition of 'business rules' (from the title). He claims definition of rules is a process business people can understand and perform without involvement of IT people.
Ross divides the problem domain into a three-sided model: facts; processes; and rules. He says facts describe the results of business operation (strangely enough almost precisely Eli Goldratt's definition of information - as opposed to data). He writes facts using a declarative sentences such as "Customer places order" (does this look familiar?). Processes are not explained in the article.
Rules are facts which are extended with "must" or "must not". Hence, "A shipment be insured if the shipment value is greater than $500."
Ross suggests that rules should be kept independent from facts and processes and that doing so exposes the processes and greatly simplifies them. He says this leads to a "thin process".
Ross' 'facts" are clearly very similar to Features. As we know processes are chains of Moment-Intervals. I am, therefore, left wondering if Ross' Rules model might be a missing link which would strengthen FDD by providing the defining requirements for Features.
Finally, Ross' has a "fact model" which looks awfully like an object model to me. Ross' model in the article really sucks - he has Person and Organization extending out of Borrower Pointing Mr. Ross at the world of Peter, Jeff and Steve may go a long way to further improving his ideas.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/
Principles of the Business Rule Approach author: Ronald G. Ross asin: 0201788934 |
Object Oriented Business Rules
To tie this to another thread I started recently, I noticed that Nicola, Mayfield and Abney have very adequately covered how to model and code business rules into a "Pattern Player" object model, in chapter 4 of Streamlined Object Modeling. An extract is available at The Coad Letter.
Hence, I am wondering if the two techniques can be married together. I'll report back on this when I've had time to try it out.
David
--
David J. Anderson
author of "Agile Management for Software Engineering"
http://www.agilemanagement.net/