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

The magnificent 7 or 7 ways to use business rules in a modern software architecture

Vote 0 Votes

I was reading Ronan's blog and saw this post about three styles of SOA. The three styles were:

  • SOA based integration
  • Modern, composite application development
  • Modernizing mainframe and legacy applications

This got me thinking about the styles or patterns of use of business rules in SOA and I came up with 7. These built on the discussions I have been having with various folks about the use of decisioning in Complex Event Processing(CEP), Business Activity Monitoring (BAM) and Business Process Management (BPM) as well as in Service Oriented Architectures (SOA) more generally. So here goes:

  1. Decision Components
    A component in a composite application is decision-centric (it has lots of rules, rules that change a lot, rules that interact in complex ways or rules that require business expertise to manage) and so should be designed and built as a decision service. It might also need to be changed often or out of synchronization with the rest of the application. In many ways these are the classic "rule services" people build with business rules.
  2. Decision Activities
    An activity in a process is a decision such as assessing credit-worthiness or deciding what cross-sell offer is most appropriate. These should be identified explicitly in the context of a Business Process separately due to synchronization issues and others (see this post for discussion of synchronization). Clearly the difference between this kind of activity and a decision component above is more contextual than real.
  3. Event Decisions
    An event requires a decision to be taken. This might be a simple event trigger (see if a particular event should be escalated or not), or tied to Business Activity Monitoring (BAM) or Complex Event Processing (CEP) software that handles much of the initial processing and event handling and only uses a decision service when the remaining decision is a business one. I have had a fairly spirited discussion on CEP and decisions with David Cameron (see this post on different uses of rules in CEP) and have blogged previously about the potential for enhancing BAM with decisions.
  4. Complex Routing
    A gateway/branching node within a process might have implied complex decisioning - in this case you are going to get routing rules in the BPMS that use a decision service to do the heavy lifting as otherwise you are going to have hidden decision logic buried in your process which is almost as bad as having it buried in your legacy code. Bruce Silver made a good point on this topic on his blog in the context of rules and BPMN.
  5. Legacy Exposure
    Part of a legacy application needs to be serviced enabled and that part is both maintenance-rich and logic-oriented not data-heavy. In practice this means you have some business logic that is part of your mainframe application, you need to re-use that logic but the maintenance burden of keeping that logic up to date is high. In this case it might make the most sense to renovate that part of the application into a rule repository, regenerate the rules into the mainframe environment and expose the rules using a rule service for the rest of your services to access.
  6. Intense Transformation
    There are circumstances in which the transformation of information is intense in a business (rather than a technical) sense. For instance, many layers of overlapping financial regulations might make transforming local accounting records into centralized ones both complex and subject to audit and compliance. A decision service to handle these transformations might be more effective than embedding those rules into a more technical environment.
  7. Enterprise Decisioning
    A growing number of companies are seeing value in treating all decisions as a corporate asset and in providing an enterprise decisioning backbone or universal decisioning engine that manages all the operational business decisions as services and makes them available to all channels and systems. This last clearly subsumes the others. There's a lot more on this over on my Enterprise Decision Management blog.

Clearly all of these can be handled the same basic way - build a set of rules, manage them and expose them as a service for others to use but it seemed useful to lay out the examples. Also, there are others, but these are the main ones it seemed to me.

Technorati Tags: , , , , , , , , , , ,

1 Comment

I thought this was a fantastic post. I've been reading up on service oriented architectures over the past week or so, and not all the information out there is laid out as neatly or clearly as you've done here. Thank you!!

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