Best Practices: SOA Application Design Analysis
Separation of concernsYou may find that when considering the design of a business process, there are actually two kinds of business-related logic that impact your design. One is directly related to how services should be orchestrated to achieve a business goal. For example, order processing may require performing an inventory check, invoking payment and shipping services. This logic will typically be unchanged once it is defined and made operational. The second kind of logic often has to do with decisions that need to be made in an orchestration flow, things such as how to evaluate risks associated with an issuing an insurance policy or how to apply a discount based on certain purchase criteria. These types of decisions tend to change a number of times during the course of the life of a business process, and could be due to changes in market conditions, for example. Furthermore, these types of changes need to be implemented dynamically to meet business needs. Timeliness is of utmost importance in these situations.
Because of these reasons, it is often desirable to separate the more volatile, business-policy based logic from the more static process orchestration logic. Instead of hard-coding these business policies into an orchestration flow, one can consider using business rules to author and manage thse business policies as artifacts held separately from the process and use a rules engine to support a business process at runtime. The combination of using business rules and orchestration flows can create a more agile and adaptive solution.
To determine whether or not business rules are appropriate for your needs, consider the following criteria.
Using business rules in process orchestration requires the adoption of business rules software and more effort is required to learn, design, develop and manage rules. You need to consider the tradeoffs.
- Are there decision points in the process that will change more often than the orchestration flow itself? If the changes happen much more often than the release cycle allowed, consider using business rules.
- Who will be the source of these changes? Are they the architects who design the orchestration flow or domain experts who do not know the inner workings of the process? If the answer is domain experts, consider utilizing a business rules management system (BRMS) to give these stakeholders the means to manage these business policies.
- How fast do these changes need to take effect? A BRMS will allow fast deployment of business policies changes outside of the normal release cycle. That being said, every change of rule should first be staged to test its impact.