Analyzing business rule statements

The previous article in this series showed how business requirements can lead to the identification and specification of business policies and rule statements. Let's now take the output of this phase and analyze it in order to determine individual atomic business rules that can be reused across the business. You can see that the example business rule statement "...potential customers must be credit checked and identified...", as expressed by our business stakeholder and captured in IBM Rational® RequisitePro®, in fact contains multiple discrete rules. You can also see that you can safely break this rule statement into distinct rules without losing any business information:

• Potential customers must be credit checked
• Potential customers must be identified

Further analysis may yield additional information as to the meaning of these elements. For example, analysis of the lifecycle model of "Customer" could yield the following, as per the Industry Models:

Based on this, you can see that "potential"> is in fact a lifecycle state for the concept of "Customer". In addition, you now have critical information about the allowed states of the concept "Customer" and the allowed transitions between states. Similarly, further analysis into the meaning of "identification" may yield the definition of further terms such as "primary identification" and "secondary identification". These may be related directly to business concepts within the models and relationships between those concepts.

Finally, analysis of related rules often has an impact on atomic rule definition. For example, analysis of related contexts may highlight that identification of customers is critical, not just while they are in the potential state, but in all other states as well. This could in turn lead to a generalization of the rule — promoting it from the domain of "Potential Customer" to the domain of "Customer". However, for the purpose of this example, we limit the scope to the domain of "Potential Customer".

All of this analysis taken together would lead to two atomic business rules:

• Customers in the potential state must be credit checked
• Customers must provide primary and secondary identification

These atomic business rule statements are also bound to business types within the Industry Model. In particular, you need to ensure that business types within atomic rule statements are defined using well-understood business types, as expressed within the normalized model of BOM.

Back to top

Relating business rule statements to atomic business rules

With the definition of increasingly formalized layers of business rules, traceability becomes a concern, not only to the models elements to which these rules relate, but also between these levels of rules. As atomic business rules are defined, they should be traced to the business rule statements from which they originate, which in turn relate to business policy. The nature of this traceability depends on the means used to express atomic rules. In the absence of dedicated tooling to support this, this example focuses on the extension of rules requirements within RequisitePro to express atomic business rules with trace relationships to the RSA BOM model, which provides the formalization of business types. This can either result in a second requirement type within RequisitePro for atomic rules, or the maintenance of a singe requirement type that evolves from rule statement to atomic rules, depending on the complexity of the rules at hand and the degree of formalization the organization wishes to achieve.

Additionally, using RequisitePro, you can create a traceability relationship between the atomic business rule and the service where this rule is invoked. For example, the RequisitePro structure Credit Check Review ("...potential customers must be credit checked and identified...") may be traced to the IDM construct analyzeCustomerRelationship.

Further leveraging traceability trees within RequisitePro allows visualization of traceability from business policy, through business rule statements to atomic business rules.

Back to top

Incorporating a business rules management system

Having established a catalog of business rule policies and statements, possibly with associated atomic business rules, you must ultimately transform this information into platform-specific formats as rule expressions. As discussed, rule expressions may take on a wide range of forms, and a key design decision is the identification of which rules are best expressed in which form. For example, which rules does it make sense to push out to an external business rule management system (BRMS), and which can safely be hard coded?

When to use a BRMS

Typical candidates for externalized rules are those that experience a high degree of flux in requirements. The primary benefit of using a rules engine over ordinary coding techniques is that rules engines allow efficient and controlled change of business rules as requirements change. Rules governing product behavior, terms, or conditions often change based on market needs and should be externalized for flexibility.

Complexity of rules is also a factor. Most rule management environments have useful capabilities to manage compound rules, decision tables, and interdependent rule elements. Rules with a high degree of complexity, such as organizational policies, may experience less change in requirements, but are good candidates for rules-based implementations because they are often difficult to express in ordinary code.

A third factor is role-based access for a variety of user roles, including non-technical policy analysts. An enterprise-class BRMS provides a collaborative environment for business users that can be synchronized with the accompanying technical environment.

A fourth factor is reuse. As you have seen, rules are often nested in nature. Fragments of rules may be highly reused. While certainly attainable in code, building these fragments within a rule management environment allows better control and management of reuse, particularly where rules are dynamic or complex.

Use of Industry Model artifacts within a BRMS

Many of the artifacts available within the Industry Models represent information useful for business rule design and authoring. A BRMS can make use of these artifacts using a variety of approaches:

• Reference links for traceability: BRMS artifacts can be associated with links to relevant Industry Model requirements and specifications. For example, bi-directional reference links could be maintained between business rule policies/statements in the Industry Models and the associated concrete business rule implementations in a BRMS.
  
  
• Direct import of standard artifacts: In some cases, Industry Model artifacts are available in a format that can be directly imported into a BRMS. For example, portions of a data model in the Industry Models may be in a format (UML, XML schema, and so on) that can be directly imported as a base data/object model in a BRMS.
  
  
• Customized tooling extensions for transformation of artifacts: When format incompatibilities do not allow direct import of Industry Model artifacts into a BRMS, custom import/export utilities may be justified in some cases.
  
  

The following sections describe these approaches in more detail in the context of a specific BRMS, ILOG JRules™.

Back to top

ILOG JRules overview

ILOG JRules provides support for authoring, testing, simulating, deploying, executing, and managing business rules.

Primary JRules modules include:

• ILOG JRules Rule Team Server: A rule management server and repository with a collaborative Web-based environment for authoring, managing, validating, and deploying business rules.
  
  
• ILOG JRules Rule Studio: An Eclipse-based integrated development environment (IDE) for technical staff that supports rule application development and debugging.
  
  
• ILOG JRules Rule Scenario Manager: An integrated environment for testing, verifying correctness of rules, and simulating changes in business policies.
  
  
• ILOG JRules Rule Execution Server: A J2SE- and J2EE-compliant rule execution environment that includes components for synchronous, asynchronous, and Web service-based invocation of business rules.
  
  

Business rules representations

Within JRules, business rules are represented in one of three alternative forms:

• Natural language-like textual rules: Using an application-specific vocabulary and a customizable grammar, rules are represented as business-friendly text.
  
  Figure 3. JRules natural language rule
  
  
  
  
  
• Decision Tables: For groups of rules that share a set of common attributes and have similar structure, it can be convenient to maintain in a tabular form.
  
  Figure 4. JRules decision table
  
  
  
  
  
• Decision Trees: Similar content as Decision Tables, but represented as a tree with branching logic.
  
  Figure 5. JRules decision tree
  
  
  
  
  

Object models and rule vocabularies

Business rules within JRules are expressed using a vocabulary of terms and phrases that are derived from an underlying Business Object Model (BOM).

The JRules BOM in turn is derived from a concrete eXecutable Object Model (XOM) consisting of technical artifacts such as Java classes and XML schema. When a BOM element is directly associated with a single specific XOM element with no transformation required, no explicit mapping between the associated BOM and XOM elements is required. In other cases, an explicit BOM-to-XOM mapping can be specified to define how the BOM element can be derived from one or more XOM elements. For example, suppose a BOM element for a customer's age is needed, however the underlying XOM only contains a customer birth date. A BOM entry for customer's age can be defined with an associated BOM-to-XOM mapping that performs a date difference calculation using the birth date.

Executable rule services

Business rules are deployed to the runtime rule execution environment (Rule Execution Server) as groups of rules called rulesets. A ruleset represents an executable service with well-defined input/output parameters that form a published service interface. These runtime rule services can be invoked using standard service execution mechanisms such as SOAP-based Web services, JMS messaging, or EJB/POJO calls.

Back to top

Integrating JRules with IBM Industry Models

Maintaining traceability to requirements

Business rule artifacts maintained within the framework of the Industry Models often form the requirements for concrete business rules implemented within a BRMS. It then becomes important to maintain reference links between the requirements and implementation artifacts. The requirements artifacts could consist of any combination of levels of business logic: business policies, business rule statements, atomic business rules, or all.

One straightforward approach for maintaining this type of traceability is to add appropriate metadata to both the requirements artifacts and the BRMS artifacts. At a minimum, this metadata can be free-form text; but specific reference data such as URLs or artifact names/IDs would be more useful.

For example, one way this metadata could be implemented using RequisitePro and JRules is as follows:

• For requirements artifacts within RequisitePro (policies, statements, atomic rules), a custom property can be added that contains a reference to a specific rule or group of rules within JRules. This reference could be a name or description, or it could be a specific URL within JRules Rule Team Server that would allow direct navigation to the appropriate artifact within the BRMS environment.
  
• For business rule artifacts within JRules, a custom property can be added that contains the name (or names) of associated RequisitePro requirements artifacts. JRules allows adding any number of custom properties to rule artifacts, where the custom properties can be simple string descriptions or structured data objects.
  
  

Importing artifacts from IBM Industry Models

The typical process for creating rule vocabularies within JRules is as follows:

• Import XOM as a combination of XML schema and Java classes
  
  
• Generate default BOM and Vocabulary from the XOM
  
  
• Extend the BOM as needed by creating additional BOM elements with associated BOM-to-XOM mappings
  
  
• Refine Vocabulary as needed for readability
  
  

The XML schema and Java classes available within the Industry Models can be imported directly as part of the first "Import XOM" step above.

For example, suppose you're going to implement a rule-based decision service for the "Analyze Customer Relationship" activity identified in the above RequisitePro example. The Analyze Customer Relationship activity will be specified by means of a WSDL that defines a service interface, and associated with the WSDL will be the XML schema that define the message content for the service. You can import these XML schema into ILOG JRules to form a base XOM for ruleset creation.

Figure 8 provides a fragment of an XML schema exported from IFW that defines the concept of "Customer". Note that this export is an extract of the IFW IDM model as an XML schema using the WSDL/XSD generators.

Included within this definition is the attribute "lifecycleStatus", defined as follows:

After importing into JRules, JRules BOM entries and associated vocabulary are generated. Figure 10 illustrates how the lifecycleStatus attribute of Customer appears within the Rule Studio BOM Editor:

In particular, note how a "verbalization" of lifecycleStatus is generated:

The verbalization is a combination of plain text and placeholders. In this particular verbalization, the placeholder "{lifecycle status}" represents a subject phrase, which in this case defaults to "lifecycle status", and the "{this}" placeholder represents the containing class, which in this case is a Customer. When authoring rules, users see some placeholders automatically filled in and others that they define using drop-down lists or text.

Figure 11 illustrates how the resulting vocabulary element could appear within business rules:

Automatic generation of JRules artifacts using custom tooling extensions

JRules allows the creation of business rule artifacts programmatically by means of a published Java API. Examples of artifacts that can be created in this way include:

• Business rules
• Business rule templates
• BOM and Vocabulary elements
• Business rule organizational structure (package hierarchy)

In cases where specific Industry Model artifacts provide sufficient detailed information for generating corresponding JRules artifacts, automated generation of the JRules artifacts can be considered using custom translation code. This can take the form of an Eclipse plug-in, as a custom export plug-in for RequisitePro, for example, or a custom import plug-in for Rule Studio.

Back to top

Decision service interface based on Industry Models

At this point, you can expose a Web service (WSDL) interface to your defined rule set, which can be invoked by a service consumer such as a business process. Note that because we used the Industry Model-derived XSD specifications in constructing our rules, we now have a direct correlation between the data parameters of our rule Web service and the rest of the IFW derived infrastructure.

Back to top

Conclusion

Rules analysis and design using IBM Industry Models follows a defined lifecycle of the definition of rules requirements, analysis of atomic rules, and the definition of target-specific rules expressions. Additionally, there are a number of patterns that may be observed that will assist significantly in maintaining the integrity of a rules architecture over time. Development of rules as a service provides a critical degree of isolation between rules consumers and rules providers, while binding rules to the elements of the industry models to which they relate allows a clearer picture of rule reuse and interdependency.

Additionally, the ILOG business rule management system provides capabilities to specify, manage, and execute these rules. Driving the specification of ILOG rules from the IBM Industry Models ensures a maximum understanding of the reuse potential of business rules and the business contexts within which they execute.

There are, however, significant opportunities to automate elements of this rule lifecycle, resulting in greater consistency of rule definition and better alignment with business requirements in the future.

Resources

Learn

• IBM Industry Models and ILOG business rules management systems, Part 1: Define business rules using IBM Industry Models (developerWorks, September 2008): Consider rules analysis and design during Industry Models deployment stages, and how rules can be identified and managed.
  
  
• "Building Service-Oriented Banking Solutions with IBM Banking Industry Models and Rational SDP" (IBM RedPapers, October 2007): Follow this step-by-step guide to working with the Industry Models in the Rational SDP
  
  
• ILOG BRMS Resource Center: Learn more about ILOG BRMS.
  
  
• developerWorks Information Management zone: Learn more about Information Management. Find technical documentation, how-to articles, education, downloads, product information, and more.
  
  
• Stay current with developerWorks technical events and webcasts.
  
  
• Technology bookstore: Browse for books on these and other technical topics.
  
  

Get products and technologies

• Build your next development project with IBM trial software, available for download directly from developerWorks.
  
  

Discuss

• Participate in developerWorks blogs and get involved in the developerWorks community.
  
  

About the authors

Brian Byrne has over 10 years of experience in the design and development of distributed systems, spending 7 years driving the architecture of Industry Models across a range of industries. Brian is currently an architect within the IBM InfoSphere brand.

Greg Imirzian is a senior technical alliance manager at ILOG, working with ILOG partners in a wide range of industries to determine how best to apply business rules and optimization technologies within Service-Oriented Architecture environments. Greg has over 20 years of experience in the design and development of software systems for advanced decision support.

Janet K. Wall is a Senior Product Manager and Marketing Manager for the BRMS Products at ILOG, focusing on the product strategy and requirements for the specialty BRMS markets. Janet has 20 plus years of Business Rules and Information Management experience for Business Application Design and Implementation on multiple platforms.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Analyzing business rule statements
• Relating business rule statements to atomic business rules
• Incorporating a business rules management system
• ILOG JRules overview
• Integrating JRules with IBM Industry Models
• Decision service interface based on Industry Models
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into Information Management on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers