Task: Define Discovery Roadmap |  |
The definition of the discovery roadmap is an important step to understand how the development team will extract the rules from the different kind of sources. There are multiple types of roadmaps according to the different starting points and rule sources.
Relationships
Roles | Primary: Rule Analyst | Additional: Business Analyst Project Manager | Assisting:
Inputs | Mandatory: Decision Point Table | Optional: Business Process Map Use Case Use-Case Model | External: None
Outputs | Rule Discovery Roadmap
Main Description
There are two dimensions to consider when preparing the rule discovery activities or roadmap: The type of source for rule harvesting The type of analysis used by the project team: use case approach, business process modeling, mission policies analysis Tony Morgan in his book "Business Rules and Information Systems: Aligning IT with Business Goals" proposes the following discovery processed according to the different source above: The static analysis process uses reading and highlighting the rules within documentation. The elicitation is based on reading session completed with Question / Answer workshop sessions Interactive involves a Subject Matter Expert who has the knowledge of the business process and the decisions to take to process a given business event.The process will be done by using elicitation workshop Automated involve using a computer and special application to search for rule statement within procedure code, SQL procedures, code listing... Code review should always be complemented by workshop sessions for Q&A. So for each decision point within the DP table do the following steps
Steps
Review the decision points table with stakeholders and prioritize them
Review the decision points with the stakeholders and set the priority on each decision point. Depending of the complexity of the business process the team should prioritize which rule harvesting to tackle first. A good practice is to start with a simple, well understood decision point, to help training the team on the practice, but keep also in mind that the management wants to see the business value of what the team is working on. So a decision point that is important by bringing a value, should be in the top of the list. If needed review the business context to keep the business needs and reassess the priority accordingly. It is important to start by extracting rules that is bringing immediate value to the business users, to get their buy in, and motivation to continue to do this painful work. It may be relevant to start with the most complex business scenario. It helps convincing business users and rapidly enriches the conceptual data model. It is important to set the expectation among the stakeholders that not all the rules will be discovered during this phase. The goal is to complete a rule set up to 40-60% to have some tangible decision on standard business event to process. The rule writers or the development team will enhance the Rule Set later on. One good practice is to implement the decision logic using rules for the main stream of business processing, letting the exceptions to the human. It will be always possible to add rules to manage some newly discovered exception later on. A typical case is in the underwriting type of rules. An expert will quickly extract some basic rules that always need to be true to accept the Application. As soon as the discussions start to be around the "but there is a case where ..." a lot of new rules will arrive.
Select acquisition process according to the source of rule.
Select the acquisition process according to the source of rule: Map the rule source to a suitable acquisition process: Human => workshop session Documentation (legal) => Active reading followed and Q& A sessions Code => Mining followed Q&A sessions and design sessions When the source is people we need to start individual interview to get the core of the knowledge and then follow up with workshops to resolve outstanding issues and process exception paths with the team. Modify for each decision point in the table the acquisition process chosen and the owner of the process
Properties
Predecessor | Review Decision Point Table, Business Process Map, Use Case Model
Multiple Occurrences |
Event Driven |
Ongoing |
Optional |
Planned |
Repeatable |
More Information
Guidelines | Different Rule Discovery Types
This program and the accompanying materials are made available under the Eclipse Public License V1.0, which accompanies this distribution. EPF Copyright.