Recruiting and Organizing Business Rules Talent
Many business rules are hard-coded in legacy systems. Modifications to hard-coded business rules require change requests that are prioritized against other wanted functionality, thereby hampering agility. Increasingly, we are attempting to manage business rules as data to meet rapidly-evolving business needs. As we shift to building systems that implement configurable business rules, we must recruit and train experts to think in rules. We see the need for a new kind of worker, a Rules Analyst, who can write and manage executable rules.
Identifying required skills
- Business expertise: Rules Analysts must understand the business. They require a deep understanding of business processes and of the gaps and overlaps with other related processes. If processes are data intensive, the analysts must understand the data and the relevant business semantics of the data schemas. In order to cover the spectrum of business rules authoring, either a single business expert must have both depth and breadth, or separate (depth and breadth) experts must collaborate. The Rules Analysts must have access to the owners of business policies.
- Pattern recognition: Rules Analysts need strong analytical skills. They must glean patterns from processes and data. They need to identify recurring patterns, filter data, and generalize themes that can be expressed as business rules.
- Abstraction: Rules Analysts must abstract data or process behavior into rules. Experienced Rules Analysts discover patterns in data — and then take the next step … to find the patterns of patterns.
- Precision: Experienced Rules Analysts learn to differentiate requirements for new functionality from rules about behavior. They drive IT development towards a rules implementation, possibly using decision tables expressed in a spreadsheet. They know that rules expressed at requirements time need not be an exhaustive list of rules but should provide a robust sample of rules for testing new functionality. Ultimately, the business Rules Analyst will own and control the rules.
- Collaboration: Rules Analysts must work with business clients and with system developers. Rules Analysts need to be good at translating hand-waving generalities into executable detail, working with a variety of personality types and business familiarity levels.
Searching for candidates
- Business operations: A business expert having a familiarity with business policy and experience managing data would be a candidate to be a Rules Analyst. Such a person would understand the business semantics and policies and would be able to spot an incomplete or ambiguous rule.
- IT: The kind of IT person that would be a good business Rules Analyst is one who has done some development and who also has a good understanding of business processes. The best IT candidates will have experience in expressing rules in decision tables.
- Logistics: People who deal in transportation networks develop logic skills that derive from experience in the fields of network analysis and game theory.
- Legal: People who write and maintain legal contracts have sensitivity to the concept of 'watertight-ness'. They think naturally in terms of RuleSpeak®. Contracts must be explicit, cohesive, and comprehensive.
Not all business and IT professionals are good candidates to become Rules Analysts. Looking at a person's experience is probably the best indicator of their suitability to be a Rules Analyst. Looking at work they have documented in the past may indicate the precision and structure they have applied to previous projects. Inquiring about their engagement in games of logic can be an indicator.
The person who is good at the kind of pattern recognition required to glean rules typically enjoys games. They likely played games growing up and work puzzles as an adult. They possibly studied in a technical field dealing with numbers in a large way, such as math, physics, engineering, accounting, or computer science.
As organizations mature, they should give thought to identifying and rewarding the progression of skills from junior to senior level, and to teaching new analysts. Ideally they will be:
- Recognized by the organization for their special skills.
- Ranked and rewarded according to their contributions, including their thought leadership.
- Brought together as a group to develop their collegiality and to perform as backup for each other.
- Full-time or near-full-time analysts (and preferably full-time employees).
- Offered opportunities to attend industry forums.
Case Study with Scenario
As a fun way to prepare Rules Analysts for the process of gleaning and articulating business rules, we developed an exercise modeled on a familiar build-to-order sandwich model. The goal is to specify the rules precisely, optimally, and in the correct sequence.
Mike loves sandwiches. He loves them so much that after visiting his favorite sandwich store in New York, he realized that he could organize a better process and offer a lower price just by writing down a few rules for his employees. He lays the ingredients out so that his customers can see their choices and so that his staff can quickly assemble the sandwiches. The rules for assembling ingredients into a customer's sandwich are as follows:
Bread: Every sandwich must have exactly one bread. (Mike has three choices for bread: White, wheat, and sourdough.) A patron must choose a half or a whole loaf for a sandwich.
- A regular sandwich must have at most one meat.
- A meat-lover's sandwich must have at most two meats.
- (Mike offers 5 choices for meat: Turkey, Roast Beef, Ham, Salami, Pepperoni.)
Cheese: A sandwich must not have more than one cheese. (Mike offers American and Swiss cheese.)
Vegetables: A sandwich must have all the vegetables that a patron wishes. (Mike offers lettuce, tomato, peppers, onions, olives, sprouts, and pickles.)
Doug walks into Mike's Sub Shoppe. Mike has a new employee, Jerre, who is in training. Jerre poses questions to Doug that leave too much room for ambiguity. Doug has a sly sense of humor and strays away from the prescribed sandwich script. While illustrating a rules encounter, the scenario also gives clues (in parentheses) to a possible user interface.
Jerre: Good morning! What can I do for you today?
Doug: I'd like my car washed!
Jerre: I mean what would you like for lunch today?
Doug: I'd like a spicy enchilada.
Jerre, slightly frustrated: Um, this is a sandwich shop.
Doug: Oh! In that case, I'd like a tuna salad sandwich on rye bread.
Jerre, sighing: Let's start over! There is our menu (pointing to the wall). What bread would you like? (pull-down list)
Jerre: Half or whole loaf? (radio button)
Jerre: Toasted? (radio button)
Jerre: Mustard, mayo, or both? (check boxes)
Jerre: Now you can choose one or two meats. (check boxes)
Doug: Just roast beef.
Jerre: What kind of cheese? (pull-down list)
Jerre: And which of the vegetables that you see here? (check boxes)
Doug: All of them, with extra peppers please.
Jerre: Thanks. Your sandwich is complete.
There are several things we can learn about rules specification from the Sub Shoppe scenario. In the scenario, Jerre is acting as a rules executer to develop Doug's sandwich. Mike is the Rules Analyst who designed a repeatable process based on business rules.
From the scenario we notice that:
- Questions must be precise so as to determine the rules to execute.
- Many rules can be specified as options that can drive a User Interface.
- Gleaning of rules is best done in a dialogue between two or more business experts (Doug and Jerre). Getting to an understanding that there are precise business rules is part of the discovery.
In conclusion, we advocate that rules analysis talent needs to be explicitly developed and managed. Not all subject matter experts possess natural talent for rules analysis. We advocate that Rules Analysts be recruited based on their natural skills and inclinations, and then developed into a valued pool of talent through working with other competent analysts.
# # #