| <?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.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.5.0" xmi:id="-zJrrd5jHHhFAcnOJTOW4rQ" |
| name="cycle_approach,_ftAoIAjrEdyj5bYZ0eCR5g" guid="-zJrrd5jHHhFAcnOJTOW4rQ" authors="Jerome Boyer with some revision done by Steve Nunez" |
| changeDate="2009-07-09T14:25:59.904-0700" 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>
 |
| <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 alt="" src="./resources/cycle1.bmp" />
 |
| </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,&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 alt="" src="./resources/cycle2.bmp" />
 |
| </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 alt="" src="./resources/cycle3.bmp" />
 |
| </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 artefacts 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 alt="" src="./resources/cycle4.bmp" />
 |
| </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 alt="" src="./resources/cycle5.bmp" />
 |
| </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> |
