You’d Like to Say Yes to a Rule Engine: Here’s How to Prepare for Success in Your Implementation
It can be exciting to envision the day when the functional business logic currently trapped in your code is now implemented and managed by subject-matter experts (SMEs) in rules. It can also be pretty amazing to think of the day when the actual rules of your business drive your mission-critical business processes.
But going from “here” to “there” requires a lot of advance planning. And the more realistic your upfront planning, the more likely your implementation of business rules will make it to a production-ready rule application.
Here’s a quick overview of the must-do steps involved in taking an idea from conception to production once you’ve invested in a rule engine.
1. Understand When the Rules Will Be Called
Know at what point(s) in the business process the rule engine will be invoked. Given that InRule® is a stateless engine, get a sense of the general shape of the data that will come into InRule at runtime and whether you’ll pass in one instance of your objects or many in a batch. At this stage it’s also important to begin to envision how you will create your entity schema in InRule (from a .NET assembly, imported from XML, from Dynamics CRM or SalesForce.com, manually, etc.).
2. Know and Define Your Business Rules
Settle on a scope for what the rules should accomplish. You can always revise that scope later, but the more specific and well defined your scope, the more likely your rule project will hit its targets.
After you have settled on a scope for the project, it’s important to determine the smaller scope for your initial effort (your project POC). This will help drive your SMEs and your development staff through the rest of this process.
3. Understand and Clarify Your Inputs and Outputs
It is time to settle on a specific data model. Data models can change after rule development begins, but at this point it is absolutely critical to your project’s success that the core elements of your inputs and outputs are discovered and defined down to the individual field level. As you begin the process of creating your rule application(s) and your rules, you will need to be able to confirm your specific inputs and outputs. This of course leads to #4, below:
4. Ensure that Test Data Will Be Available
Attempting to author rules before test data is available is a sure sign that you’ll need to revisit those rules sooner or later. And of course the more realistic your test data, the more likely you’ll be able to get your rule writing correct the first time around. You can always fudge test data during unit testing, but real data drives proves out the decisions of your data model, and provides for better testing.
5. Bonus: Your Rules are Mapped to Your Data Model
This final “bonus” topic is the ultimate goal state for implementing rules: the point where your rules have actually been mapped to the fields and relationships of your data model. In my experience, very few customers have their business rules defined to this degree, but all projects get here eventually. I have helped a number of customers document their rules to this level of specificity, and the results are always useful: implementation of rules can begin almost immediately after this stage.
If you’ve made it this far, I’m happy to reward you with a quick summary of when your solution design is ready for rule authoring. If you need assistance with any stage of this process, please feel free to contact the ROAD Services group. We would be happy to help!
Best of luck with your authoring projects!
