« Business rules, routing rules, event rules | Main | Now you can have design-time agility and great performance »

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: BAM, BPM, BPMS, BRE, BRMS, Business Process Management, Business Rules, CEP, enterprise decision management, legacy modernization, SOA, EDM

Posted by jtaylor in Business Activity Monitoring • Business Agility • Business Process Management • Business Rules • Decision Technologies • Legacy Modernization • SOA |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/689

Posted by: RisingSunofNihon at September 14, 2006 02:29 PM