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

Focusing on decisions to improve the software end product

user-pic
Vote 0 Votes

The Forrester Blog For Application Development & Program Management Professionals had a post on a 21st Century Software Development Process that reminded me of one of my favorite topics - the need for programmers, especially Agile programmers, to get on the business rules/decision management train. In writing the post Dave makes some good points and has this to say about Agile:

a focus on culture, knowledge, and skills will instead improve the end product. This change in emphasis is embodied by the Agile methods movement and described nicely in one principle in the Agile manifesto 'Individuals and interactions over process and tools'

Now there are four tenets in the Agile Manifesto and this is the first.It has always seemed to me that this one almost forces a proponent of the Agile approach to adopt business rules for specifying the logic in business decisions as, after all, one of the key interactions is between developers and domain experts. Business and domain experts don't like code or other technical representations and the evidence is overwhelming that they do like rules. Because rules are declarative, rich in semantics and verbose they are easy for business users to understand and even write and this helps the individuals concerned (developers and business users) have a better interaction. In fact I would go as far as to say that a developer who claims to be doing Agile while still writing code that is procedural, terse and focused on syntax is not applying this tenet at all.

The other tenets also show the value of rules and decision management.Working software over comprehensive documentation because business rules can deliver working software that domain experts can manipulate directly lessening the pressure for documentation. Customer collaboration over contract negotiation because rules allow developers and customers to directly collaborate on the the implementation of business logic. Responding to change over following a plan because business rules deliver business agility by making the actual code you write easier to change both during the project, and after it.

So if you are a developer who likes to say you are doing Agile, are you using business rules or are you just deluding yourself?

BTW I wrote an article on this topic a while back for InfoQ - Agile Rules

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

Fico

Subscribe

 Subscribe to this blog by RSS
Subscribe by email:

Recently Commented On

Recent Webinars

    Monthly Archives

    Blogs

    ADVERTISEMENT