• Interchange of Human-oriented Business Rules

This is a detailed description of one of the general General Use Case Categories abstracted from the possible Use Cases.

1. Abstract

This use case is not about interchange of rules between people. It is about interchange of rules between tools that support people, referred to as “rule specification and editing systems” in the discussion below. Its value has two aspects:

• Businesses have to cope with large numbers of rules, originating from many different sources, often with overlapping scope and sometimes with conflicts. They need tools in which rules can be formally defined, analyzed and organized. The tools themselves are outside the scope of the RIF WG, but the RIF WG ought to be concerned with support for interchange of rules between them.
• An important requirement for interchange is that, increasingly, businesses cannot by themselves cope with the volume and scope of the rules that affect them. They rely on shared interest groups and expert advisors, and need to be able to acquire rules from these sources and integrate them into their own rule specification and editing systems.

CLARIFICATION OF SCOPE

Excluded from this General Use Case Category

• Rules that are not formally specified.
• Direct person to person communication of rules independent of rule interchange between rule editing systems.
• All of the rule specification, analysis and management functions in the rules editing systems (tools) for people who run organizations.

• Human processing of rules, i.e. rule interpretation, inference and enforcement actions by people (but not excluding the specification of rules themselves that may be so interpreted by, inferred from, or enforced by people).

• Any form of rules that is not fully declarative including procedural rules or rules containing actions (except that there is a requirement to interface with these types of rules).

• Broad business policies which need to be transformed into actionable rules for implementation.

• The mapping of rule and vocabulary meanings to all the different forms for structuring their meaning, and the definition of such forms for structuring meaning (except, of course, RIF; but not excluding the requirement to be able to be mapped to all these forms of meaning).

• The mapping of all the different rule and vocabulary forms for structuring meaning to the syntax/grammar of natural or artificial languages, and the definitions of any grammars, syntax and notation, including Controlled English.

Included in this General Use Case Category

• The interchange of the structure of the meaning of rules, and the vocabulary (‘terms and facts’) in terms of which the rules are formulated, between:

  • instances of the same or different kinds of rule editing systems/tools for people who run organizations, Rules Systems Supporting Interchange of Human-oriented Business Rules Rules Systems Supporting Business Communication of Rules, that support specification, analysis, verification & validation of rules in business terms using controlled natural language underpinned by formal logic.

  • the above ‘rule editing systems’ and all other types of rule systems, especially rule-enabled IT application development environments for, and/or rule system components of, the IT systems that support the organization’s business processes.
• All the kinds of rules, and the vocabulary (‘terms and facts’) in terms of which the rules are formulated, that are:
  • structured in a way that is interpretable in a formal model theory.
  • In the fully declarative form of rules
  • actionable
  • to be interpreted by, inferred from, or enforced by either people or computers
  • used by people who run organizations:
    • Regulations
    • Definitional Rules
    • Rules governing the operation of the organization (corporate governance, regulatory compliance, organization roles and responsibilities, workflow)

    • Rules specifying rule enforcement declaratively, i.e. the set of conditions required immediately upon completion of the enforcement action

    • Rules specifying products and services
    • Rules governing relationships, transactions and agreements with parties internal or external to the organization

      • Trading Agreements (buy/sell products & physical items)

      • Service Provision Agreements
      • Managed Service Agreements (In-house and/or Outsourced)
        • IT Service Agreements
        • Facilities Management Agreements
        • Call Center Agreements
      • Employment Contracts
      • Professional Service Contracts
      • Rental Agreements
        • Property Rental (e.g. apartment rental, storefront rental
        • Property Leases (e.g. 999 year flat leases in UK)
        • Equipment Rental (e.g. car rentals)
      • Construction/Manufacturing Contracts (e.g. make a dam, an airplane)
      • Partnership and Merger Agreements
      • Regulations imposed on the organization

EXAMPLE OF A HUMAN-ORIENTED BUSINESS RULE

• (from the EU-Rent case study used in the OMG’s SBVR, “Semantics of

  • Business Vocabulary and Business Rules” specification)

  “A EU-Rent car must not be handed over to a driver who appears to be intoxicated.”

This rule can be expressed formally, but will not be automatically applied (at least, not with the technology currently in use in car rental companies). It will be applied by people who work in EU-Rent.

There are two important aspects of this. First, people who apply rules need decision support. For example, EU-Rent staff would need criteria for judging whether a driver is intoxicated; SBVR (and, I think, REWERSE) would categorize these as structural rules.

Second, people don’t always do what they are supposed to, so enforcement will be needed. This may have two levels:

• Penalties applied to the organization if it breaks rules. If EU-Rent hands cars over to drunks, will it be fined, closed down, charged as an accessory to criminal offences? We could call this ‘external enforcement’.
• Penalties applied within the organization to the responsible person. If a person in EU-Rent hands a car over to a drunk, will he/she be reprimanded, be fired, become ineligible for legal support from EU-Rent in the event of criminal charges? We could call this ‘internal enforcement’.

For both types of enforcement, there may be rules that escalate the penalty for repeated offences.

USE CASE DESCRIPTION

There is a need for interchange of rules directed at people as well as for interchange of automatable rules. This general use case category, “Interchange of Human-oriented Business Rules”, is for rules editing systems that support rules that are meant to be understood by people, regardless of whether such rules can be automatically enforced or applied by computers.

“Organization to Organization” Rule Interchange

What is common about the “Interchange of Human-oriented Business Rules” general use case category is that it deals with all the regulations, actionable policies, rules, terms & condition, etc. that occur in the real world running of any kind of organization, including governmental, not for profit, educational organizations, etc.

This rule interchange is between of different organization units within an organization or between organizations. It occurs at the micro level between rule editing systems of different work groups, and at the macro level between rule editing systems of national governments and multi-national corporations.

In addition, businesses are increasingly reliant on external sources regarding their policies and rules. For example:

• EU-Rent could buy or license a standard car rental contract (including a “no drunk drivers” rule) from an industry association, and adapt/extend it to meet EU-Rent’s specific requirements.
• For judging intoxication, EU-Rent could adopt criteria from a recognized authority. These criteria would support a defence stronger than one based on criteria that EU-Rent had made up for itself, if an aggrieved customer were to sue EU-Rent for being over-zealous or if the police were to prosecute EU-Rent for being under-zealous.
• EU-Rent does not have to research the external enforcement rules (which may vary between countries and states) for itself. It could: share the costs and effort by participating in a trade association; buy the rules from an expert source; obtain them directly from regulators.
• When EU-Rent has decided on internal enforcement rules, it could check them out with trade associations (for comparison with peer practice), employee unions, regulators and other interested parties.

The Rules Interchange Format is needed for interchange of rules in these situations between the tools of an organization and external bodies, or between different units within a distributed organization.

“Organization to IT System” Rule Interchange

Organizations, which manage their business policies and rules as part of governing and operating their organization and/or specifying their products and services, want to delegate the execution and enforcement of a significant part of their rules to information systems.

An organization requiring technology support for such rules would need:

1. Tools to store, organize and quality-assure human-oriented business rules. Most businesses have lots of these rules, originating in different parts of the business, and many of them are inter-related. My example rule affects EU-Rent’s terms and conditions for car rental, its employment contracts, its insurance contracts, and its regulatory compliance policies, to name just the obvious ones. Businesses need tools (better than Word and Excel) to integrate the rules, to categorize them, and to support analysis of overlap, redundancy and conflict - which requires their interpretability in formal logic. This requires a repository in which the rules can be stored in semantic structures that enable analysis and classification, with functionality to support searching, queries, comparison, checking for conflicts and overlaps, etc. It should also support recording of issues and conflicts discovered and decisions on how to resolve them taken by the organization. The tools themselves are outside our scope. The industry is developing them in response to the OMG’s SBVR (“Semantics of Business Vocabulary and Business Rules”) specification.
2. Support for creating technology solutions:
   • transforming automatable rules to machine-processable form
   • mapping non-automatable rules to IS functions that support the people who have to apply the rules
   There are also two things to think about for the bigger picture. One is that the business intent expressed in the human-oriented business rules is the source of many of the automated rules that are more ‘mainstream’ to the RIF WG. The other is that many human-oriented business rules can be more-or-less directly automated. For example:
   • “If a rental car is dropped off at a location other than the agreed return location, a penalty charge must be added to the rental cost”
   There is the basis here for a continuum from business motivation to deployment of automated rules, but we should probably postpone discussion of it until after we have established the basic requirements for supporting human-oriented rules.

2. Status

• Originally proposed by John Hall [“xxxxxxxxxx .. need a homepage …”], Donald Chapin [“DonaldChapin”], and Said Tabet [“SaidTabet”].

• The “Rules Systems Supporting Interchange of Human-oriented Business Rules” is based on the OMG specification, “Semantics of Business Vocabulary and Business Rules (SBVR)”, that provides:
  • a business vocabulary for creating and documenting Business Rules and the Business Vocabulary on which they are formulated using controlled natural language underpinned by formal logic,

  • a corresponding metamodel for rule editing, analysis, verification & validation systems/tools.

  The SBVR specification was submitted to the OMG and/or is supported by these commercial or academic organizations:
  • Adaptive
  • Automated Reasoning Corporation
  • Business Rule Solutions LLC
  • Business Rules Group
  • Business Semantics Ltd
  • Fujitsu Ltd

  • Hendryx & Associates

  • Hewlett-Packard Company

  • InConcept

  • LibRT

  • KnowGravity Inc

  • MEGA
  • Model Systems
  • Neumont University
  • Perpetual Data Systems
  • Sandia National Laboratories
  • The Rule Markup Initiative
  • Unisys Corporation
  • X-Change Technologies Group

Implementations for "Organization to Organization" Rules Interchange

• Implementations are in various stages of development and deployment:
  • Unisys “Rules Modeler” (available as product Spring 2006)
  • University of Lecce “Business Modeling Language” Tool (beta available end of Q2 2006)
  • Neumont University “ORM Object Role Modeling) Tool” (available as Open Source Q3 2006)

Implementations for "Organization to IT" System Rules Interchange

• Implementations of the SBVR specification are in various stages of development and deployment:
  • Unisys “Rules Modeler” (available as product Spring 2006)
  • Neumont University “ORM (Object Role Modeling) Tool” (available as Open Source Q3 2006)
  The basis for “Rules systems for designing and/or operating information systems” half of the rules interchange for this use case are enumerated in the List of Rules Systems [“List of Rules Systems”] along with their formal basis and implementation status.

Implementations for Interpretation and Interchange of "Regulations"

• The basis for “Interpretation and Interchange of Regulations” in addition to the above is a candidate OMG RFP, currently being created by the Regulatory Compliance SIG of the OMG, would include within its scope a metamodel for interpreted regulation and related compliance action. This would be build on top of the SBVR metamodel and the OMG’s new “Business Motivation Model” (BMM) specification. Implementations are in various stages of development and deployment:
• … to follow

3. Links to Related Use Cases

“Organization to Organization” Rule Interchange Related Use Cases

• Product Compatibility:

  • A major aspect of the “Product Compatibility” use case is the interchange of product rules among parties along the supply chain when making buy, sell, and product usage agreements.

• Enterprise Information Integration:

• Information Integration with Rules and Taxonomies:

  • Agreements are usually between people in different organizational uts, and therefore often define the point at which semantic disconnects occur within business vocabulary, rules and information. The “Enterprise Information Integration” and “Information Integration with Rules and Taxonomies” use cases cannot integrate information from within two or more disparate organization units without dealing with the integration of the business language and business rules of the disparate organizational units.

• Credit Card Transaction Authorization:

  • The “Credit Card Transaction Authorization” use case represents one kind of agreement covered by this use case.

• Supply Chain Ordering Lead Time:

  • The sharing of policy rules about lead time in the “Supply Chain Ordering Lead Time” is part of the process for making agreements about shipping and delivery dates.

• Refund Policies in E-Commerce;

• Price Discounting:

• E-Procurement Contract Exchange, with Default-Inheritance Ontologies:

  • ‘Contracts’ in the “Refund Policies in E-Commerce”, “Price Discounting”, and “E-Procurement Contract Exchange, with Default-Inheritance Ontologies” are a key form of ‘agreements’.

• Interpretation and Interchange of Regulations:

• Interchange of Business Rules between People Who Run Organizations and Internally/Externally Supplied IT Systems:

  • Both the “Interpretation and Interchange of Regulations” and “Interchange of Business Rules between People Who Run Organizations and Internally/Externally Supplied IT Systems” are, along with this use case, examples of the General Use Case “Rules Systems Supporting Business Communication of Rules”.

• Rule Interchange Through Test-Driven Verification and Validation:

  • Verification and validation of business rules both for internal consistency and for the accurate statement of business intent is an integral part of this use case.

“Organization to IT System” Rule Interchange Related Use Cases

• Situation Assessment and Adaptation:

  • In order for the business user to be able to ask for the information and rules he/she needed, and to understand and interpret the reply, in his own terms and context (in this example, convoy operations), the “Situation Assessment and Adaptation” use case needs this use case to connect the semantics and logic of the user’s business language, rules and frame of reference with the structure and mechanics of the IT rule system storing and process the information and rules.

• Enterprise Information Integration:

• Information Integration with Rules and Taxonomies:

  • The “Enterprise Information Integration” and “Information Integration with Rules and Taxonomies” use cases need this use case to connect the semantics and logic of the user’s business language, rules and frame of reference with the structure and mechanics of the IT rule system storing and process the information and rules.

4. Relationship to OWL/RDF Compatibility

The class of rule systems that this use case refers to is based on the integration of linguistics and predicate logic. Although the linguistics aspect loosely follows a descriptive logic approach, it has not be formalized as such. The integration of and/or mapping rules for first order predicate logic and .description logic, which seems to be a generic challenge to the creation of the RIF, is the point where this use case touches on OWL/RDF compatibility.

5. Examples of Rule Platforms Supporting this Use Case

“Organization to Organization” Rule Interchange Platforms

• Unisys “Rules Modeler”
  • Commercial tool for business users to specify their business terms, facts and rules that implements SBVR and has additional transform function to generate some kinds of application code.
• University of Lecce “Business Modeling Language” Tool
  • An EU-sponsored tool for European SME (Small and Medium-sized Enterprises) that enables their participation as suppliers in large commercial projects.
• Neumont University “ORM (Object Role Modeling) Tool”
  • A new open source ORM tool enhanced with SBVR capabilities that has additional transform function to generate database designs, schemas and triggers.

“Organization to IT System” Rule Interchange Platforms

• Unisys “Rules Modeler”
  • Commercial tool for business users to specify their business terms, facts and rules that implements SBVR, and has additional transform function to generate some kinds of application code.
• Neumont University “ORM (Object Role Modeling) Tool”
  • A new open source ORM tool enhanced with SBVR capabilities that has additional transform function to generate database designs, schemas and triggers.

6. Benefits of Interchange

“Organization to Organization” Rule Interchange Benefits

• Much higher probability of successful delivery under the agreement and satisfied parties at the end.
• Makes it difficult for the other party to misunderstand and/or re-interpret the terms and conditions of the agreement.
• Much less likelihood of costly default and/or recourse to the courts.
• Enables regulated organizations to interchange shared understanding of interpretation of regulations that affect them

  • The whole point of creating agreements and contracts is that two or more different parties, each with their own sub-dialect of business language and terms, are creating a mutually understood and committed set of ‘terms & conditions’ that will govern them and other subsidiary participants in their delivery under the agreement.

    Being able to interchange these agreements and contracts (sets of terms & conditions) between tools that support specification, analysis and quality assurance of rules in business terms using controlled natural language underpinned by formal logic great improves the likelihood that this will happen.

• This area of business is increasingly being standardized and regulated. For example, from June 2006 most new property leases in the UK will have to contain a number of prescribed clauses.
• The volume of such business rules, their complexity and the level of interaction between them means that tools are needed to manage them effectively
• Businesses are increasingly using externally-defined formulations of such rules, from sources such as trade associations and knowledge vendors.
• Enables automated support for comparison of regulations from different regulatory sources
• Enables regulated organizations an easy access to regulations published on the Web in a vendor-independent fashion (companies will focus more on the content as opposed to the infrastructure around regulations)

“Organization to IT System” Rule Interchange Benefits

• Reduced costs from an automated bridge between rule editing, analysis, verification & validation systems/tools containing rules as used by people who run organizations, and the IT modeling and development tools that create the information systems that support the operation of the organization.

• Greatly reduced semantic loss between the rules the people who run organization want to operate by and the rules actually executed in information systems.
• Substantially increased ability to operate the organization flexibly in response to market and other external conditions.
• Enables integration of interchanged regulation into a suitable web repository

7. Requirements on the RIF

“Organization to Organization” Rule Interchange Requirements

• specify all the kinds of rules used to govern and operate an organization and/or specify its products and services,, including definitional rules (formally structured definitions of terms).
• specify the rules in terms of a vocabulary/metamodel that is:
  • rich enough to provide all the kinds of terms and relations among them that need to be referenced to specify all kinds of RIF rules.
  • mappable to Higher Order Predicate Logic (restricted to Henkin semantics) in support of SBVR which provides the human-oriented mechanisms.
  • mappable in both directions, without semantic loss, to a subset of natural language grammar structures that are sufficient to express in natural language all kinds of terms and relations among them that need to be referenced to specify all kinds of RIF rules.
• mappable to Higher Order Predicate Logic (restricted to Henkin semantics) plus ‘deontic’ and ‘alethic’ modal operators in support of SBVR which provides the human-oriented mechanisms.
• exchange, without semantic loss, the meaning of each rule independent of, and transformable to/from, both particular formulations and/or expressions (in a language) of it.
• be mapped in both directions, without semantic loss, to a subset of natural language grammar structures that are sufficient to express all kinds of RIF rules in natural language.
• In addition to providing a format for interpreted regulations, the RIF must provide formats for:
  • Compliance action, with discrimination between minimum mandatory requirements and recommended good practice
  • Compliance objectives and goals agreed with regulators
• Concept definitions and a default (English) vocabulary for regulation and compliance.
• The RIF format needs to support the expressiveness required for the representation of regulations (both conditions and actions)
• RIF to interface with these types of rules
• ... (incomplete)

“Organization to IT System” Rule Interchange Requirements

• ...(incomplete)

8. Breakdown

8.1. Actors and their Goals

“Organization to Organization” Rule Interchange

• Organizations that have to integrate rules from many different sources into a coherent rulebase for their own business
  • To understand their rights, responsibilities, risks and recourse.
  • To understand to constraints under which they must operate in addition to their specific facilities management terms and conditions.
  • To ensure compliance with organizational objectives, strategy and policy.
  • To meet its compliance obligations with minimum impact on its business and minimum risk.
    • One important aspect of compliance is to be able to demonstrate compliance on demand – i.e. compliance is not just a defence when things go wrong. It must be demonstrable when things are going right. A corollary of this is to defend the decisions made and actions taken when found to be out of compliance – acting in good faith (e.g. as suggested in the USA sentencing guidelines) can have a substantial mitigating effect.
• Organizations that collaborate to form agreements (lessor/lessee, supplier/purchaser etc.)
  • To ensure that their terms and conditions express their interests in a way that will gain agreement of the other party.
  • Fully understand the terms and conditions being levied upon them to:
    • be able to see all their reasonable business implications.
    • negotiate the terms and conditions to fit their business interests as well.
• Expert advisors, who provide rules that have some kind of added value, e.g. industry consensus, legal precedent, negotiation with regulator (lawyers, industry groups, regulators’ advisory services).
  • To ensure that the agreement is enforceable.
  • To understand clearly and unambiguously the terms and conditions of the agreement.
  • To know the terms and conditions to which they might add value
  • To represent its members (regulated organizations) within a country, across multiple industries. Negotiates with regulators on data protection and privacy, ranging:
    • From: clarification of the regulator’s intent: “If our members took the regulation to mean this … would you agree that it is an acceptable basis for taking decisions about action?”
    • To: agreement on acceptable compliance: “If our members did this … in response, would you accept that it is acceptable action for compliance?” Provides the results to its members in both push and pull modes, using the Web as a distributed standards-based platform.
  • to represent its members (regulated financial organizations) in negotiations with regulators on financial controls and reporting.
• Regulators (e.g. governmental agencies)
  • to ensure that regulated organizations comply with their regulations, and can demonstrate their compliance.
  • To ensure compliance with regulations
• Auditors, inspectors, ombudsmen
  • to verify that the rules (1) are fit for purpose, and (2) are in practice in the business.

“Organization to IT System” Rule Interchange

• People Who Run Organizations (using the Rules Editing, Analysis, Verification & Validation System)

  • To be free to specify their business rules in ‘controlled’ natural language from their own organizational point a view and in terms of the language they use when running the organization.
  • To have their business rules implemented in the information system without any change or loss of meaning or intended business effect or business data content
  • To be able to change their rules as needed and have them take effect quickly
  • To be in control of every rule that influences the business effect or business data content produced by the operation of the information system.
• System Developers (using the Rule-enabled IT Application Development Environments)
  • To have the rules provided by people who run organizations
    • so clear, unambiguous and actionable that they can get on with developing a high quality information system knowing exactly what they have to implement without wasting a lot of time trying to get the requirements clear.
    • Specified, structured and interpretable in formal logic in a way that enables largely automated (under the guidance of the system developers) transforms to rules in the language required by the rule platform used in the information system.
• Rule System Components of the Information System
  • To be given rules in its own language that, as a set of rules, have integrity within its approach to rules processing and its interpretation of formal logic

8.2. Main Sequence

Provide the typical course of events, ordered as below in a sequence of steps.

1. First step of sequence

2. ...

3. Last step of sequence

8.3. Alternate Sequences

Describe possible variations of the main sequence in separate subsections, assigning a title to each.

8.3.1. (Title of Alternate Sequence)

Describe the alternate sequence, referring to the steps in the main sequence above if convenient (to avoid repetition).

9. Narratives

Describe possible scenarios illustrating the use case in separate subsections, assigning a title to each.

9.1. (Title of Narrative)

Describe an individual scenario. Samples rules and other test data may be optionally included.

10. Commentary

Comments, issues, etc. Again, note that the wiki automatically keeps a revision history.