Hi
I will share a lunch time slot with Daniel Selman, tuesday 10/12 at RuleFest to present the Agile business rules development methodology, and how to leverage it for your own project.
I would love to see more projects using BRMS and rule technology as early as possible in the SDLC life cycle, than doing months of documentation.... I undertstand the SI goals to spend, burn hours on documentation work, but the value is on executable rules that brings value to the business quickly, and the business users being able to change these rules as he wants. Documentation never made good software. Good code does. Good business rules too.
See you at RuleFest.
Monday, October 11, 2010
Saturday, October 9, 2010
New release of ABRD 1.5.1
You can find a new release of Eclipse Process Framework, practices library, and ABRD. A published version is available at http://www.eclipse.org/downloads/download.php?file=/technology/epf/OpenUP/published/abrd_published_1.5.1_20101007.zip
Still working on the book.
Still working on the book.
Wednesday, March 17, 2010
Policies and Rules – Improving business agility articles
There are two new articles about business rules and business policies on developer work which may my readers. I participate deeply in this paper when joining IBM last year. Most of the concepts are known, and some are part of ABRD.
Part 1 deals with terms, abstract concepts and relationships, Part 2 describes techniques for applying the concepts to business problems.
Please feel free to comment here.
Part 1 deals with terms, abstract concepts and relationships, Part 2 describes techniques for applying the concepts to business problems.
Please feel free to comment here.
Thursday, February 4, 2010
How to find decision point
In ABRD we propose to start the rule harvesting process by looking at decision points. Recently I have a question from a business user, on how to extract the decision point. So let give some practices I'm using.
A decision point is a task in a business process or a step in the use case that involve decision to be taken. When looking at a task description it is important to search for mental thinking verb, most of the time there is a set of knowledge to apply to execute this task, which leads to decision. This could be human knowledge or business logic implementation in a software component. The type of decision will most likely be a reject or accept of the business event or flag it for future processing downstream in the business process. The decision may also include some computational expressions to assign value to attribute of the business transaction.
Therefore to find decision point in a business process or use case description start by searching for verb like analyze, check, validate, evaluate, verify. You can also leverage industry model and business process description. When there is a human task and conditional node you can expect to find decision point there. A human task can also sub decomposed in an automatic task which perform the main stream of decisioning and the exception done by the expert. In most business process there is the existence of validation step to ensure data quality: those steps are source for business rules. Decision point enforces the execution of business rules. The implementation can be done in different technology depending of the type of rule.
It is recommended to define the interface of each decision point and then consider the implementation choice later. Using rule engine technology is the best choice when business users want to change the business logic over time, to enforce auditability to trace the decisions done on a given business event. During the inception phase the project team is doing business modeling activities which aim at describing the business process and decisions applied to any business events supported by the application. Decision points are extracted at that moment and logged in the decision point table.
A decision point is a task in a business process or a step in the use case that involve decision to be taken. When looking at a task description it is important to search for mental thinking verb, most of the time there is a set of knowledge to apply to execute this task, which leads to decision. This could be human knowledge or business logic implementation in a software component. The type of decision will most likely be a reject or accept of the business event or flag it for future processing downstream in the business process. The decision may also include some computational expressions to assign value to attribute of the business transaction.
Therefore to find decision point in a business process or use case description start by searching for verb like analyze, check, validate, evaluate, verify. You can also leverage industry model and business process description. When there is a human task and conditional node you can expect to find decision point there. A human task can also sub decomposed in an automatic task which perform the main stream of decisioning and the exception done by the expert. In most business process there is the existence of validation step to ensure data quality: those steps are source for business rules. Decision point enforces the execution of business rules. The implementation can be done in different technology depending of the type of rule.
It is recommended to define the interface of each decision point and then consider the implementation choice later. Using rule engine technology is the best choice when business users want to change the business logic over time, to enforce auditability to trace the decisions done on a given business event. During the inception phase the project team is doing business modeling activities which aim at describing the business process and decisions applied to any business events supported by the application. Decision points are extracted at that moment and logged in the decision point table.
Subscribe to:
Posts (Atom)