Task: Identify Candidate Services from Business Rules
This task is performed to identify candidate services that will encapsulate business rules and policies that need to be accessed, in a uniform manner, from multiple systems.
Disciplines: Architecture
Purpose
The purpose of this task is to capture and externalize rules and policies that might need to change when the organization's business model, products, and service offerings change.
Relationships
RolesPrimary Performer: Additional Performers:
InputsMandatory:
    Optional:
      Outputs
        Main Description

        As is described in Concept: Business Rule Analysis, larger businesses increasingly use Business Rules Management Systems (BRMSes) to author and externalize their business rules.  BRMSes can automate the creation of access layers, such as Web services or Java™beans, for accessing the business rules programmatically.  In such an environment, the task related to identifying candidate services largely devolves to the IT staff working with the business analysts to document the services that the BRMS automatically generates.

        Organizations that have not yet adopted a BRMS will need to use a more conventional approach for identifying candidate services from business rules.  The steps in this task largely are intended for the use of such organizations.  The final step -- Update candidate service portfolio and service hierarchy -- is valid for organizations using a BRMS, as well.

        Tool Mentor: Build a SoaML Service Model Using the SoaML Template is the entry point into a family of tool mentors that collectively describe how to build a SoaML-based service model using IBM® Rational® Software Architect.  This tool mentor provides an overview description of a process for using the tool to create the model.  It includes callouts to several other tool mentors that accelerate Service Identification efforts.

        Steps
        Identify which rules need to be externalized

        Rules whose use is limited to a single application, or that change infrequently, are candidates for services that you should NOT externalize.


        For reactive business rules, identify pertinent triggering events, execution conditions, and actions.

        Business rules fall into two broad categories: 

        • Inference rules (IF this, THEN that), which  are commonly stateless rules that are encountered during the execution of procedural applications; and
        • Reactive rules, which are triggered by specific events, run if a specific condition is valid, and which perform a specific action -- such as a database modification.  Reactive rules commonly are executed by a system that monitors its surrounding conditions.  As an example, when a particular item in a grocery store falls below a certain number of on-shelf items, that might trigger a restocking order.

        In this step, focus on reactive rules.  The triggering event, transition condition, and action taken need to be documented.  If the candidate service is selected later for exposure, these three items will need to be addressed during the implementation of the service that realizes the rule.

        Decide which conditions and actions need to be externalized
        For reactive rules, the execution conditions and the actions are points of potential variability.  They are candidates for externalization as services.
        Apply the Rule Pattern Language, or similar best practices, to determine rule types and understand how to realize rules.

        The Rule Pattern Language [ARS01] defines 21 best practices for categorizing and realizing business rules.

        Update candidate service portfolio and service hierarchy
        Add the new candidate services to the candidate service portfolio.   Position them within the candidate service hierarchy, in alignment with your chosen taxonomic approach.
        Key Considerations

        Business rules and policies that are subject to change need to be externalized to reduce opportunities for error.  Service enablement and using business rules engines are two approaches to externalization.

        Alternatives
        Use of a business rules engine to externalize business rules.  Such engines commonly come provisioned with a service-oriented interface that provides access to the rules engine.
        More Information