Martin Fowler always writes interesting things on his site and this one was no exception: Will DSLs allow business people to write software rules without involving programmers? In it he says:
…greatest potential benefit of DSLs comes when business people participate directly in the writing of the DSL code. The sweet spot, however is in making DSLs business-readable rather than business-writeable
And I think he is absolutely right on both points. This is exactly the value proposition of business rules – greatest benefit from business users editing business rules but broadest value from making business logic business-readable. Shared readability for business and IT users improves collaboration, improves accuracy and increases agility. I would go further and say that a business rules management system that allows templates and a business vocabulary (as all the leaders do) allows you to deliver a Declarative DSL (DDSL) quickly and efficiently.
Following the thread on Martin’s site I then found his piece on Rules Engines. This is more mixed. He describes them nicely and mak…
Copyright © 2009 James Taylor. Visit the original article at Decision Management and software development III – DSLs.
Martin Fowler always writes interesting things on his site and this one was no exception: Will DSLs allow business people to write software rules without involving programmers? In it he says:
…greatest potential benefit of DSLs comes when business people participate directly in the writing of the DSL code. The sweet spot, however is in making DSLs business-readable rather than business-writeable
And I think he is absolutely right on both points. This is exactly the value proposition of business rules – greatest benefit from business users editing business rules but broadest value from making business logic business-readable. Shared readability for business and IT users improves collaboration, improves accuracy and increases agility. I would go further and say that a business rules management system that allows templates and a business vocabulary (as all the leaders do) allows you to deliver a Declarative DSL (DDSL) quickly and efficiently.
Following the thread on Martin’s site I then found his piece on Rules Engines. This is more mixed. He describes them nicely and makes the point that
people (wisely) tend to use rule engines just for the sections of a system
I call these Decision Services or Decision Agents as that is what rule engines are best at – automated decisions. Then Martin makes a comment that is less helpful:
You can build a simple rules engine yourself
This is less than helpful. After all, you can go and build a database yourself too but you probably shouldn’t. With the great business rules products available (from open source with Drools, to pureplays like Fair Isaac, ILOG (now IBM), Corticon or Innovations Software to hosted solutions like Intelligent Results or Zementis), building one is silly. Just use one from the wide palette that’s available.
He also says:
With a production rule system, it seems easy to get to a point where a simple change in one place causes lots unintended consequences, which rarely work out well.
My experience is that the reverse is true. Impact analysis for declarative, atomic, independent rules is much easier than it is for code. Martin’s positions on not using rules when you have lots of rules or chaining (I would advise the opposite in both cases) are also do not appear to be based on the current generation of products.
Business rules work and work well, lots of products exist so you don’t need to buy one and you can use them to build powerful Declarative DSLs. After all, as Johan den Haan said in:
The structure of Domain-Specific Languages:
DSLs can be implemented using various structures, like textual languages, graphical languages, wizards and interactive GUIs, or a
combination of the previous
or a business rules management system.
I wrote more on this before
