| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-zJrrd5jHHhFAcnOJTOW4rQ" name="cycle_approach,_ftAoIAjrEdyj5bYZ0eCR5g" guid="-zJrrd5jHHhFAcnOJTOW4rQ" authors="Jerome Boyer with some revision done by Steve Nunez" changeDate="2008-12-15T02:40:28.000-0800" version="1.0.2"> |
| <mainDescription><p style="MARGIN: 3pt 0in"> |
| The Agile Business Rule Development (ABRD) Methodology provides a framework that project teams may adapt to meet the |
| needs of their specific business rules application project. The methodology supports the full rule lifecycle, from |
| discovery to governance by using an 'agile', iterative approach. ABRD activities fall into five categories described |
| below. Each of these activities is executed multiple times as the process is followed.<br /> |
| </p> |
| <ul> |
| <li> |
| <p class="MsoNormal" style="MARGIN: 3pt 0cm"> |
| Rule Discovery |
| </p> |
| </li> |
| <li> |
| <p class="MsoNormal" style="MARGIN: 3pt 0cm"> |
| Rule Analysis |
| </p> |
| </li> |
| <li> |
| <p class="MsoNormal" style="MARGIN: 3pt 0cm"> |
| Rule Design |
| </p> |
| </li> |
| <li> |
| <p class="MsoNormal" style="MARGIN: 3pt 0cm"> |
| Rule Authoring |
| </p> |
| </li> |
| <li> |
| <p class="MsoNormal" style="MARGIN: 3pt 0cm"> |
| Rule Validation |
| </p> |
| </li> |
| <li> |
| <p class="MsoNormal" style="MARGIN: 3pt 0cm"> |
| Rule Deployment&nbsp; |
| </p> |
| </li> |
| </ul> |
| <p class="MsoNormal" style="MARGIN: 3pt 0in"> |
| Like all agile methodologies, in ABRD rules as other software element are developed incrementally, in multiple |
| iterations of short time frames. However, in ABRD, the entire process lifecycle may not be followed for each iteration. |
| Instead, a number of very short cycles between phases may occur, with the entire rule set gradually evolving. The |
| entire process may be represented by the process flow diagram below:<br /> |
| </p> |
| <p class="MsoNormal" style="MARGIN: 3pt 0cm"> |
| <img alt="" src="resources/life_cycle_horizontal.bmp" /> |
| </p> |
| <p> |
| <br class="MsoNormal" style="MARGIN: 3pt 0cm" /> |
| In the process flow diagram above, each of the tasks loops back to previous tasks in the flow. These 'loops', or |
| cycles, are repeated as required, with the loops gradually moving from left to right through the process until the rule |
| sets are deployed. This method of rule development reflects the nature of BRMS: a mature and stable domain object model |
| is a prerequisite for rule development, therefore we may multiply cycles through the early part of the process flow in |
| order to develop such models early in the process. As each of these cycles is completed, the ruleset will gradually |
| grow until it reaches a state where it reflects the requirements set forth by the business. |
| </p> |
| <h4> |
| <span |
| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'; mso-bidi-language: AR-SA; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-font-family: 'Times New Roman'; mso-bidi-font-size: 12.0pt"><span |
| style="FONT-FAMILY: 'Arial','sans-serif'; mso-ansi-language: EN-US">A typical&nbsp;ABRD Project</span></span> |
| </h4> |
| <p class="MsoNormal" style="MARGIN: 0in 0in 12pt; TEXT-INDENT: 0in; mso-prop-change: 'Steve Núñez' 20080723T0858"> |
| From a project management perspective, there are five phases, or activities of project, each of which maps onto parts |
| of the technical process flow described above. The project phases are: |
| </p> |
| <ol> |
| <li> |
| <div class="MsoNormal" |
| style="MARGIN: 0in 0in 12pt; TEXT-INDENT: 0in; mso-prop-change: 'Steve Núñez' 20080723T0858"> |
| Harvesting, the activity of gathering business rules |
| </div> |
| </li> |
| <li> |
| <div class="MsoNormal" |
| style="MARGIN: 0in 0in 12pt; TEXT-INDENT: 0in; mso-prop-change: 'Steve Núñez' 20080723T0858"> |
| Prototyping, the activity of&nbsp; entering business rules into the BRMS |
| </div> |
| </li> |
| <li> |
| <div class="MsoNormal" |
| style="MARGIN: 0in 0in 12pt; TEXT-INDENT: 0in; mso-prop-change: 'Steve Núñez' 20080723T0858"> |
| Building, the activity of building a working system representing the organizations business rules |
| </div> |
| </li> |
| <li> |
| <div class="MsoNormal" |
| style="MARGIN: 0in 0in 12pt; TEXT-INDENT: 0in; mso-prop-change: 'Steve Núñez' 20080723T0858"> |
| Integrating, the activity of deploying the rules to an execution environment suitable for end to end testing |
| </div> |
| </li> |
| <li> |
| <div class="MsoNormal" |
| style="MARGIN: 0in 0in 12pt; TEXT-INDENT: 0in; mso-prop-change: 'Steve Núñez' 20080723T0858"> |
| Governance, the activity of monitoring, maintaining and enhancing business rules&nbsp;<br /> |
| &nbsp; |
| </div> |
| </li> |
| </ol> |
| <h5 class="MsoNormal" style="MARGIN: 3pt 0cm"> |
| Cycle 1- Harvesting |
| </h5> |
| <h5 class="MsoNormal" style="MARGIN: 3pt 0cm"> |
| &nbsp; |
| </h5> |
| <p class="MsoNormal" style="MARGIN: 3pt 0in"> |
| Rule harvesting, consisting of the Discovery &amp; Analysis tasks, involves gathering together all the sources of |
| knowledge available to the team. These sources may include a business process description, subject matter experts, |
| policy manuals or other sources of rules. The goal of this activity is to understand the Domain Object Model within the |
| scope of the application and to identify enough rule patterns to begin implementation of rules in the next phase. |
| </p> |
| <p class="MsoNormal" style="MARGIN: 3pt 0in"> |
| During this activity, the development teams divide the day into two parts, executing discovery workshops in the morning |
| (in 2 or 3-hour sessions), then performing analysis and documentation for the remainder of the day. The team iterates |
| on these two steps during 2 to 5 days maximum, depending on the number of rules and their complexity<br /> |
| </p><br class="MsoNormal" style="MARGIN: 3pt 0cm" /> |
| <br /> |
| <p class="MsoNormal" style="MARGIN: 3pt 0cm"> |
| &nbsp;<img height="222" alt="" src="resources/cycle1.bmp" width="242" /> |
| </p> |
| <p> |
| <br class="MsoNormal" style="MARGIN: 3pt 0cm" /> |
| <span |
| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'; mso-bidi-language: AR-SA; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-font-family: 'Times New Roman'; mso-bidi-font-size: 12.0pt">The |
| starting point of the Rule Discovery is a</span> <span |
| style="FONT-SIZE: 10pt; COLOR: #003399; FONT-FAMILY: 'Arial','sans-serif'; mso-bidi-language: AR-SA; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US"><a |
| class="elementLink" href="./../../../practice.tech.abrd.base/guidances/templates/decision_point_table_AB877257.html" |
| guid="_kRoWgBDFEdyJtJ3PbfdVDw">Decision Point Table</a>&nbsp;</span>artifact<span |
| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'; mso-bidi-language: AR-SA; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-font-family: 'Times New Roman'; mso-bidi-font-size: 12.0pt">:&nbsp; |
| During the inception phase (See OpenUP for more information)&nbsp;the project team is doing business modeling |
| activities (not covered here) which aim at describing the business process and decisions applied to any business events |
| supported by the application.&nbsp;One important work product built during&nbsp;this modeling phase is the&nbsp; <span |
| style="FONT-SIZE: 10pt; COLOR: #003399; FONT-FAMILY: 'Arial','sans-serif'; mso-bidi-language: AR-SA; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US"><a |
| class="elementLink" href="./../../../practice.tech.abrd.base/guidances/templates/decision_point_table_AB877257.html" |
| guid="_kRoWgBDFEdyJtJ3PbfdVDw">Decision Point Table</a>&nbsp;</span></span><span |
| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'; mso-bidi-language: AR-SA; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-font-family: 'Times New Roman'; mso-bidi-font-size: 12.0pt">which |
| describes the point in the process (task, activities, transition) where decisions are made.&nbsp;Decision point |
| represents potential candidate for rule sets.</span> |
| </p> |
| <p> |
| <br /> |
| <strong>Cycle 2- Prototyping</strong> |
| </p> |
| <p> |
| The prototyping activity extends the tasks performed to include rule authoring. When a workable number of rules (this |
| number will vary by project) have been harvested the development team should start to define the structure of the rule |
| project: the rule set parameters (input-output business objects), and the basic sequencing of the rules (the <a |
| class="elementLink" href="./../../../practice.tech.abrd.base/guidances/termdefinitions/ruleflow_27B05442.html" |
| guid="__2sZYBCWEdyJtJ3PbfdVDw">ruleflow</a>), and the major elements of the <a class="elementLink" |
| href="./../../../practice.tech.abrd.base/guidances/termdefinitions/bom_6AC0E84F.html" |
| guid="_1iTjABCXEdyJtJ3PbfdVDw">Business Object Model</a>. The team should then be able to already implement some rules. |
| </p> |
| <p> |
| Tip: During the first pass through the prototyping activity, it is better to err on the side of too few rules |
| </p> |
| <p> |
| A best practice is to execute the step "Rule Authoring" as soon as possible to uncover possible analysis and design |
| issues. Indeed, most of the rules look good on paper but real issues arise most of the time during implementation and |
| test. The next morning workshop session communicates the issues back to the business team. This leverages the feedback |
| loop approach and provides an efficient mechanism to build a pragmatic, adequate and business-relevant executable rule |
| set.<br /> |
| </p><br /> |
| <br /> |
| <p class="MsoNormal" style="MARGIN: 3pt 0in"> |
| &nbsp;<img height="249" alt="" src="resources/cycle2.bmp" width="470" /> |
| </p><br /> |
| <br /> |
| <p class="MsoNormal" style="MARGIN: 3pt 0cm"> |
| <strong>Cycle 3- Building</strong> |
| </p><br class="MsoNormal" style="MARGIN: 3pt 0in" /> |
| <br /> |
| <p class="MsoNormal" style="MARGIN: 3pt 0in"> |
| The goal of the build activity is to create rules that can be 'seen', 'used' and, most importantly, tested, by business |
| users. Rules that can be executed by the rule engine are more valuable than ones defined on paper or in abstract forms. |
| This fully endorses the agile statement: "Working software over comprehensive documentation." |
| </p> |
| <p class="MsoNormal" style="MARGIN: 3pt 0in"> |
| The second goal of this phase is to create a set of realistic test scenarios, using real data if possible, to test the |
| rules created during the Authoring activity. This is a form of Test Driven Development (TDD). This activity extends the |
| Build activity by adding a Rule Validation task.<br class="MsoNormal" style="MARGIN: 3pt 0cm" /> |
| <br /> |
| </p> |
| <p class="MsoNormal" style="MARGIN: 3pt 0cm"> |
| &nbsp;<img height="249" alt="" src="resources/cycle3.bmp" width="619" /> |
| </p><br class="MsoNormal" style="MARGIN: 3pt 0cm" /> |
| <br /> |
| <p class="MsoNormal" style="MARGIN: 3pt 0in"> |
| The&nbsp;day-to-day authoring activities consist of a series of&nbsp;small steps that include: |
| </p> |
| <ul> |
| <li> |
| <div class="MsoNormal" style="MARGIN: 3pt 0in"> |
| Test case implementation |
| </div> |
| </li> |
| <li> |
| <div class="MsoNormal" style="MARGIN: 3pt 0in"> |
| Writing rules and executing rules |
| </div> |
| </li> |
| <li> |
| <div class="MsoNormal" style="MARGIN: 3pt 0in"> |
| Validating&nbsp;rules with the business team members. |
| </div> |
| </li> |
| </ul> |
| <p class="MsoNormal" style="MARGIN: 3pt 0in"> |
| The build activity consists of all the previous tasks, with short iterations: |
| </p> |
| <ul> |
| <li> |
| <div class="MsoNormal" style="MARGIN: 3pt 0in"> |
| Enhance rules (Authoring &amp; Validation tasks) |
| </div> |
| </li> |
| <li> |
| <div class="MsoNormal" style="MARGIN: 3pt 0in"> |
| Improve rules (Analysis, Authoring &amp; Validation) as needs are identified |
| </div> |
| </li> |
| <li> |
| <div class="MsoNormal" style="MARGIN: 3pt 0in"> |
| Complement rules (Discovery, Analysis, Authoring &amp; Validation) with additional rules to provide complete |
| coverage of the business domain (once every two days). |
| </div> |
| </li> |
| </ul> |
| <p class="MsoNormal" style="MARGIN: 3pt 0in"> |
| The Building activity should take between two and three weeks, and the output artifacts should be a ruleset that can be |
| loaded into the rule engine and executed. |
| </p> |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px"> |
| <p class="MsoNormal" style="MARGIN: 3pt 0in"> |
| Checkpoint:<br /> |
| <em>During the first iteration of this activity, the total number of rules will be only around 40% to 60% |
| completed. The idea is to get something to business users that is sufficient to get comment and feedback on, and |
| that will form the basis of the next phase. By this point, the Business Object Model (BOM) should be at least 90% |
| complete</em>.<br /> |
| </p> |
| </blockquote><br class="MsoNormal" style="MARGIN: 3pt 0in" /> |
| <br /> |
| <p class="MsoNormal" style="MARGIN: 3pt 0in"> |
| Depending on the size of the ruleset, this activity may deliver less than 40% of the rules. In that case, this activity |
| may have to be repeated. In this situation, it is recommended that the activity be time-boxed to three weeks so that a |
| concrete build may be delivered to the QA or validation team for review. Once a build is delivered, another iteration |
| of this cycle may be started.<br /> |
| </p> |
| <p class="MsoNormal" style="MARGIN: 3pt 0in"> |
| At the end of this cycle it is possible to release the rule set integrated as a&nbsp;decision service into the core |
| business application. The development team can then execute functional test on it. |
| </p> |
| <p class="MsoNormal" style="MARGIN: 3pt 0in"> |
| <br /> |
| &nbsp; |
| </p> |
| <p class="MsoNormal" style="MARGIN: 3pt 0cm"> |
| <span style="mso-spacerun: yes"><strong>Cycle 4- Integrating</strong></span> |
| </p> |
| <p> |
| <span |
| style="FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'; mso-bidi-language: AR-SA; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-font-family: 'Times New Roman'; mso-bidi-font-size: 12.0pt">The |
| goal of this cycle is to deploy the rule set under construction to the execution server in order to test it with an |
| end-to-end scenario. The integration of the decision service and the&nbsp;domain object model is an important task. |
| Integration involves the marshalling of data to/from external data sources, such as Database, MOM, files or sockets |
| into a form that can be understood by the execution engine. This is a 'mapping' of the data received by the decision |
| service to the Business Object Model created in previous activities.<br /> |
| There are a number of tools and techniques that can be used to marshal data, and the best choice will vary by project. |
| When this activity is complete, data (preferably 'real' data) will be sent to the rule engine to fire rules, make |
| decision and the results delivered over the same channels as the production system. These test scenarios were developed |
| in previous phases, but now they're being run with all of the 'plumbing' in place. In the future they will serve as |
| non-regression test suite<br /> |
| </span>&nbsp; |
| </p> |
| <p> |
| &nbsp;<img height="160" alt="" src="resources/cycle4.bmp" width="208" /> |
| </p><br class="MsoNormal" style="MARGIN: 3pt 0cm" /> |
| <br class="MsoNormal" style="MARGIN: 3pt 0cm" /> |
| <br /> |
| <p class="MsoNormal" style="MARGIN: 3pt 0cm"> |
| <strong>Cycle 5- Enhancing</strong> |
| </p> |
| <p class="MsoNormal" style="MARGIN: 3pt 0in"> |
| Cycle 5 is used during the development phase as well as during the rule maintenance or governance activity.&nbsp;One of |
| the goal here is to empower business users or at least business analysts to author and test the rules. |
| </p> |
| <p class="MsoNormal" style="MARGIN: 3pt 0in"> |
| The Enhancing cycle is a transition phase in which last minute changes can be made involving some short, face to face |
| discovery meetings with SMEs (Subject Matter Experts) to wrap up any outstanding issues or questions before entering |
| the Governance activity. The Governance activity is an open-ended, long running process to enhance and maintain the |
| rules created in previous activities. A governance process will vary by organization and is a fundamentally different |
| process, usually performed by a different team than the rule development team. This team is more business oriented and, |
| as owners of the rules and business policies, they can develop at their own pace, using the infrastructure put in place |
| by the development team.<br /> |
| <br class="MsoNormal" style="MARGIN: 3pt 0cm" /> |
| <br /> |
| </p> |
| <p class="MsoNormal" style="MARGIN: 3pt 0cm"> |
| &nbsp;<img height="182" alt="" src="resources/cycle5.bmp" width="750" /> |
| </p><br class="MsoNormal" style="MARGIN: 3pt 0cm" /> |
| <br /> |
| <br class="MsoNormal" style="MARGIN: 3pt 0cm" /> |
| <p class="isisguidance" style="MARGIN: 3pt 0in"> |
| <span |
| style="COLOR: windowtext; FONT-FAMILY: 'Arial','sans-serif'; mso-bidi-font-family: 'Times New Roman'; mso-bidi-font-size: 12.0pt">It |
| is important to note that there will almost certainly be some need to enhance the object model or physical data model |
| to add some new facts, attributes, or entities. These modifications will follow the standard release management process |
| of the core business application.</span> |
| </p><br class="MsoNormal" style="MARGIN: 3pt 0cm" /> |
| <strong>Summary</strong><br /> |
| <p class="MsoNormal" style="MARGIN: 3pt 0cm"> |
| <span |
| style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-language: AR-SA; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-font-family: 'Times New Roman'; mso-bidi-font-size: 12.0pt">ABRD |
| has many advantages as a framework for the&nbsp; business rule development process. It involves all the key |
| stakeholders, provides a proven development process and a clear transition to business analysts to start the governance |
| activities . As a business application using a rule engine is, per design, very agile and supportive of changes, all |
| parts of the organization need to be brought together, such as business analysts, software architects and software |
| developers to gain an understanding early in the development process how the components exposed to the rule engine work |
| together, how to change, add, remove rules, how to deploy them</span> |
| </p><br class="MsoNormal" style="MARGIN: 3pt 0cm" /> |
| <br /> |
| <p class="MsoNormal" style="MARGIN: 3pt 0cm"> |
| <span |
| style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-language: AR-SA; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-font-family: 'Times New Roman'; mso-bidi-font-size: 12.0pt">In |
| parallel of these Rule Set development activities the software architect develops the <a |
| href="./../../../practice.tech.abrd.base/guidances/termdefinitions/decision_service_6C51F997.html" |
| guid="_M0nWsAsYEdyPCr4G1Tb79A">Decision Service</a>s&nbsp;integrated into the core business application. Each of these |
| decision services executes one or more rule sets.</span> |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
