We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

James Taylor's Decision Management

James Taylor

Using Decision Management and software development - DSLs or rules?

Vote 0 Votes
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

James Taylor blogs about decision-management technologies such as predictive analytics and business rules, discussing how they deliver agility, improve business processes and bring intelligent automation to SOA.

James Taylor

James Taylor blogs on decision management for ebizQ, and is an independent consultant on decision management, predictive analytics, business rules, and related topics.

Sponsored Links



 Subscribe to this blog by RSS
Subscribe by email:

Recently Commented On

Recent Webinars

    Monthly Archives