More than half of our rule authors identify as non-developers or business analysts. That’s great news for the business since they are closest to the problem. At the same time, it makes honing your team’s rule authoring practice critical. Decisions (including all of the underlying rule sets) sit in front of the most critical aspects of business process and revenue streams. We believe best practices (just like in software development) make rule authoring safe and predictable. Below are some practices we follow to kick-start a project.
Asking Questions
Ask your questions early and often. While there are many good starting points for a project, even seasoned practitioners need to step back when they fall into dead-ends. Consider the following questions:
- When are you ready to implement a decision as a rule application?
- How do you know you have enough requirements and a useful level of detail?
- Should you start writing rules without a stable data model (entities)?
- What if it’s all wrong and you need to start over? Worse, what will the team think if the project goes back to square one?
Generally, rule authoring is the easy part. Harvesting and expressing requirements is the hard work. Most projects hit unanticipated walls during the requirements gathering process. That being said, you can make a lot of progress even with a subset of your known requirements from a spreadsheet or document. Once you write the first couple of rules the process of harvesting requirements and converting them to new rules accelerates quickly. Rule sets that eventually hit 5,000 to 10,000 rules need more people and practice than I mention here. Let’s save that for another time and focus on the basics for now.
Courage
When faced with a blank canvas, new painters sometimes struggle to begin. Experienced painters facing a blank canvas will often say “just paint through it.” From a decision management point of view, we say “keep engaging with your project.” You do this by analyzing your data and the rules that go with it. Eventually the rule set you want will emerge in your own vocabulary and phrasing. You will know you are on the right track when new requirements stop forcing changes to entities (your data model) or the flow structures of your overall decision. Getting to a working prototype is a key milestone.
Know the End Game
Solving complex problems requires activities that simplify and break down elements of the problem. Knowing what’s important guides you and the team. Are we still producing a result that we want? Keep your focus on one working decision. If you have participated in an InRule workshop, consider periodically returning to your “Problem Statement” and your “Goal Statement” (see the blog post Good Beginnings: Agreeing on the Problem).
Test/Implement Feedback Loop
Once you are deep into authoring, you start asking questions about subtle variants. For example, you might ask yourself, “Is this decision for every case or does this apply only within a discrete set of boundaries?” The boundaries might include types of policies, risk profiles, regions, or other previously unconsidered parts of your business processes. Do any variants break what we have implemented, or worse, take us off course? Prove that your decision works for concrete outcomes (specific test cases with as-real-as-possible data) and move decision variants out of your workstream if they are out of scope for your initial effort. Delay what can come later: track your variant requirements in a backlog somewhere once you have met your goal. Stated another way, avoid optimizing (complicating) at the early stages of your initial effort. There will be time to improve what you have in future iterations against that growing backlog.
A note about testing
As a best practice, work with one of your developers to save off entity states from irVerify. A useful tip is to save the result state also (as a separate test data file) in order to permit regression-style testing. Consider setting up a batch process that executes the entity state and compares results. If the results don’t match, then we can fix the rule set or modify the tests. Many teams skimp on this practice and suffer once they are in production. A robust testing practice will prove your rule application isn’t adversely affected by future changes.
Recognize Data
Rules contain data and concepts that matter. Data must be specific even if your initial free-form rules (things in spreadsheets and documents) lack precision. If there are two or more of a noun, it probably needs to be represented as a collection. If things relate to each other like “address to customer”, then you likely are looking at a relationship that should be defined in your data model between two objects. New rule authors unfamiliar with data modeling concepts should review datatypes, structures, data relationships, and general data modeling best practices before going too far. Even if more technical team members are responsible for modeling the data in your rule application, it’s critical that you understand the data relationships they’ve arranged, and that you provide feedback if anything appears odd or missing.
Break Down the Problem
Decisions related to underwriting, eligibility, risk, fraud, and other complex areas encounter difficult problems early in a project. Often, you’ll see a comingling of complex data models mixed with severe variation in requirements. In mortgage lending, there are multiple addresses, borrowers, dependencies on state-specific requirements, regulatory mandates, and so on. When you run into this kind of roadblock, pair with someone like your team’s architect or a developer who is responsible for integration. The checklist below should be of help:
- Do we know what’s going IN and OUT of this decision modeled as entities?
- What steps are in this decision (validation, approval, feedback, errors, and notifications)? Try our Decision Management Worksheet to structure your thinking:
- Can we narrow the scope of our decision? A smaller working system is more valuable than a larger but nonfunctional one. Try focusing on specific regions, types, anything that can reduce surface area but still deliver completeness end-to-end.
- Do your entities and relationships make rule authoring cumbersome? Can we at least write one rule using what’s here and then simplify? For example, let’s use a For Each rule or an existing business language template that walks through a collection. Step back after it’s working and look for improvements. Looking for the “best” implementation adds too much pressure while trying to solve a problem the first time.
- Is it obvious to others that your rulesets have been created for a specific purpose?
- Explore vocabulary templates to make rules more readable. Is it critical that an external reader (ex: a regulator) understand what this decision does? If yes, then consider using vocabulary to simplify the way your logic is expressed.
- If you don’t like your rule implementation, but it only occurs once, spend time on the remaining parts of the rule application before applying vocabulary. Otherwise, applying vocabulary to simplify frequently used phrases accelerates delivery.
- Above all, time box your effort while you are stuck. Pair with other team members until your prototype is working. If you have ROAD service days remaining, schedule a day to pair with one of our rule authoring experts.
If you haven’t already done so, consider signing your team up for an InRule workshop. Workshops can take you from discovery to a working prototype in four days – [email protected].
Many thanks to my co-author and collaborator Rob Eaman who continues to sharpen our workshop practices and inspire customers. See Rob’s blog titled “Bridging the Gap Between Business Analysis and Technology.”
