Sunday, October 25, 2009

Basic features of a good Business Rule Framework

While working on business logic side of our application, it is often advised to have a centralized mechanism for management and execution of business logic. I have thought about some of the features that this Business Rule Framework should have. Having the features before hand would provide ease in evaluating various Business Rule frameworks available in the market.

While reviewing the text, I could see some of the overlaps between various features. But, I think, it is good to keep them separate.

1. Nesting and Sequencing of rules: The rule framework must provide us the ability to nest rules. This would allow us to decide the nested rules to be selected based on certain other rules.

2. Logical relationship between rules: For a condition, all rules should be satisfied or any rule should satisfy. In technical terms we have certain logical relationships like AND, OR etc. We want our rule engine to be providing such conditions.

3. Enabling / Disabling the rules: We should be able to enable / disable a rule under any circumstance. It means that we don’t have to delete the definition of rule but just disable it somehow so that it is not applied.

4. Rule Profiles: I don’t know this should be the name of title that I want to discuss. Let me explain what I have in mind, the rule engine must be able to decide application of rules based on the user / role / group. Its designer and engine should be able to access directory service. This would not only make the life of architect easier coz you wouldn’t have to decide in the code to select rule, this service would automatically be provided by the rule framework.

Doing so, it should be able to access the directory services so that It could select groups / users and design / apply rules based on their roles.

This profile can also be selected based on the source type. This source might include regions, devices. This is because certain regions and countries might have different rules e.g. financial and our rule framework must be able to see the source and decide which rules should be applied accordingly.

5. Business User interface: The rule framework should provide ability to provide some interface to business user so that not only they could understand the rules easily (language should be easy) but they might also be able to update those rules.

The system should also give the business users ability to create new rules and inject them at the required step.

6. Dynamic Updates: No compilation and build should be required to update business rules. It should be dynamic. As soon as rules are updated, the effect should be visible in the application.

7. Communication abilities: The business rule framework must provide abilities so that it could communicate with the hosting environment both ways. This feature should be available as desired in addition to the instant when they are called.

It should also provide ability so that it can communicate outside the hosting environment i.e. it could access any service across the available networks supporting the service oriented architecture.

8. Documentation Support: Business rules System should provide documentation feature. This can be stored as metadata of the business rules. It should allow different views of this documentation for business and technical users.

Users should be allowed to extract information from the documents by exporting them to formats generally used by users like word, CHM and Visio diagrams etc.

9. Instrumentation: This should support instrumentation so that logs can be created. It should support major instrumentation frameworks like WMI. It should allow different logging mechanisms like email, Windows Event log, log files etc.

Users should be allowed to define the formats of these logs. They should be allowed to define what information should be logged. The framework should provide certain variables like source information (user and machine), time of day etc.

10. Events for Rule Execution: There should be events for rule execution. The events might be fired on the basis of pre or post execution of rules. We might create other events which we can think of. In those events, we might be able to cancel the rules if certain condition is not satisfied.

11. Reliability and Availability: The rule engine should be reliable. It should allow consistency for users. It might also support redundancy as part of its design in case off any failure. Keeping single Rule Engine Server would introduce the Single Point of Failure in the design.

12. Storage Options: These rules might be stored in any or the combination of database, XML, compiled code options. Updating the storage options should not be visible to the client applications.

13. Seamless Just in Time Deployment: Clients must not be bothered when these rules are updated and deployed. This operation should be seamless.

This is really tricky because there would be some users which would already be executing rules at any instance.

14. Versioning of rules: System should support to maintain versions of these rules. Administrators should be allowed to maintain these versions. Client applications should be given flexibility to specify any particular version or latest version (as desired) for these rules.

15. Security: The rules must be secure. There should be some authentication mechanism. This would secure the rules from being updated by unwanted users. There should be category of rules which should be allowed to be updated by certain roles. These groups and users might be the same users as in the directory services.

16. Available for different Programming platforms: Organizations evolve. Some of the applications lose their values with time. So they are replaced with new systems. Doing that, these organizations have many applications running at the same time. They are developed in different programming platforms. (.net, java etc). The rule engine must be open to accept and services the requests from any platform. Being service oriented is the key for this.

17. Scalability and Performance: Response time is the key in in current businesses because we don't want our users to wait for the response drumming the keyboard. The system should be scalable to the number of users. This might provide provide documented hardware specifications based on the number of users. For good performance, the engine must be as light weight as possible for faster execution of rules.

18. Adaptable workflow for rules management (Approval mechanism) and Audits: We can not trust an individual for managing all the rules in every application in the entire organization. There should be some kind of approval mechanism so that updated rules are monitored and controlled. There should be detailed history of these approvals.

19. Pre-production release of rules: Organizations generally have three different environments. First is development in which the applications are developed. After development is complete, they are released for User Acceptance Testing (UAT). Once they pass UAT, they are released to Production environment. Our rule system must allow us to work like that i.e. we should have different environment to work. We should be able to release it in these environments to be satisfied before ruining the actual production processes.

20. Audits of Rule Execution: The user should be given option of creating the audit trail of execution of rules. The audit trail should have details like user, application. The system should allow user to view this information in the form of reports.

No comments: