Dispatches has been quiet for a few months, but the Business Rules Group has been busy.  In August 2003 we joined with four other organizations -- Business Semantics Ltd, Business Rules Solutions LLC, Northface University, and Unisys Corporation -- in a consortium we called 'The Business Rules Team.'  Others joined and the work is now supported by 16 organizations from Canada, France, the Netherlands, Switzerland, the UK, and the USA.

The Business Rules Team (BRT) was formed to respond to a Request for Proposal from the Object Management Group (OMG) on Business Semantics of Business Rules.^[1]

"The objective of this RFP is to allow business people to define the policies and rules by which they run their business in their own language, in terms of the things they deal with in the business, but in ways that are clear, unambiguous and readily translatable by Information systems experts into executable rules for many kinds of automated systems." ~ from OMG RFP br/2003-06-03

Business Semantics of Business Rules is part of an OMG initiative on business and system architecture.  The OMG has also requested related proposals, addressing business process specification, rule management, and the representation of production rules.

Proposals accepted by the OMG membership will be the basis for development of standards for business rules and business processes, which, over the next couple of years, should take their place alongside other OMG standards such as the Unified Modeling Language (UML).

One of the OMG’s important objectives is to encourage development of tools to support recommended standards.  So we should expect to see new tools for capturing and managing rules, for exchanging vocabularies and rules between organizations, and for automatic transformation into IT systems.

The Business Rules Team’s Submission

We started with metamodels contributed by five of the participating organizations -- the Business Rules Group, Northface University, Unisys, Sandia National Laboratories, and KnowGravity Inc -- and two ISO Standards on Terminology -- ISO 704, Principles and Methods, and ISO 1087-1, Vocabulary - Part 1:  Theory and Application.

The Business Rules Group’s contribution was our work-in-progress model for Organizing Business Concepts, the work Donald Chapin and I have been reporting in Dispatches over the past three years.

The BRT’s submission to the OMG for Business Semantics of Business Rules (which I’ll call BRT-BSBR from now on) describes a model for 'Vocabulary + Rules' that can be used to describe businesses from the owner’s perspective.

The Big Picture

The diagram provides an overview of BRT-BSBR. Before we look at the detail, it’s worth emphasizing the BRT’s overall aims:

• Where BRT-BSBR is positioned in system development
• Separation of meaning from expression
• A self-defining vocabulary
• An extensible vocabulary
• Use of natural language
• Support for adoption
• Neutrality with respect to notation and methodology

  

Positioning within system development

BRT-BSBR defines a model for business vocabulary and for business rules expressed using that vocabulary.  It is intended to support description of businesses, not the information systems that support them.  For Zachman devotees, it’s at row 2, not row 3.

We recognize that much of the content of a business description in a BRT-BSBR model could be -- and, we hope, will be -- automatically transformed into IT system specifications.  We have verified that such transformations can be made.  But the transformations themselves are outside the scope of our submission.

Separation of meaning from expression

The meaning of the business description (shown in the diagram as 'Universe of Discourse') is separate from the way it is expressed (shown on the diagram as 'Form of Expression').

This has three major advantages. It supports expression of concepts in multiple languages.  It supports local variation in means of expression.  It also supports management of meaning, as opposed to means of expression alone; the intent here is to enable business people first to agree on what they mean and then to decide what they call it.

A Self-defining Vocabulary

BRT-BSBR provides a way of defining vocabularies.  The first vocabulary it defines is its own -- the vocabulary needed to:

• define concepts and relate them to things in the business
• construct fact types and guidance
• relate concepts, fact types, and guidance to language understandable by, and acceptable to, the business.

We drew on ISO standards 704 and 1087-1 for this.

Vocabularies for specific businesses are then built using BRT-BSBR’s own vocabulary.  We used EU-Rent, the (fictitious) car rental company that appears in some of the Business Rules Group’s publications, to demonstrate how this is done.

An Extensible Vocabulary

Vocabularies for specific businesses can be built on BRT-BSBR, using the things defined within it.  But BRT-BSBR includes its own vocabulary, so vocabularies based on it are extensible.

A business area, or an individual business, may need concepts or constructs that are not built into BRT-BSBR.  The 'vocabulary for defining vocabularies' can be used to define them.

From this perspective, BRT-BSBR is more like a dictionary than a database.  You can use the words in a dictionary and the rules for forming definitions to define new words.  You could also use them to define new kinds of thing, such as compound nouns and adjectival phrases (you would use what is already in the dictionary to define what you mean by 'compound noun' and 'adjectival phrase' before you created any instances of them).  You could then add your new constructs to your dictionary, extending the range of things that can be included in it.

Generally, you can’t extend a database from within.  If you want to add new data types or data structures, you have to modify the database definition (the meta-data) using a different language to do so.  This is often referred to as 'going up a meta-level.'  BRT-BSBR accommodates multiple meta-levels and seamless crossing between them.

Natural Language as Business Language

Natural language is what business people speak.  We used natural language as our basis for BRT-BSBR.  We actually did our development in English but were mindful that some of our team speak Dutch, French, and German as their usual business languages.

BRT-BSBR’s model is described in structured English.  Its vocabulary is defined in English.  We expect business people to use BRT-BSBR models with a base vocabulary drawn from a standard dictionary.  We used Merriam-Webster Unabridged and the New Oxford Dictionary of English as the base for defining BRT-BSBR’s own vocabulary.

BRT-BSBR’s structure supports reliable translation of its own model and vocabulary into other languages.

Good Support for Adoption

We expected that businesses would want to adopt both 'naked content' and vocabulary from external sources, such as standards bodies, industry special interest groups, and professional associations.  Adoption is important for two reasons:

• It reduces the work needed to maintain a business’s vocabulary and rules.
• It enables communication between organizations that have similar interests.

So we included good support for adoption.

Notation- and methodology-neutral

Given the Business Rules Group’s earlier work, we hoped that, once we had vocabulary well defined and structured, specification of business rules would be straightforward -- and this turned out to be so.

Of course this is only part of the story.  People who want to use BRT-BSBR, and tools based on it, will also need to develop methodology and processes to identify, capture, and validate rules within businesses.

However, while recognizing the need for methodology, we have kept BRT-BSBR methodology-free.  We have enough experience and variety of practice within the Business Rules Group to be confident that there is no risk in doing this.  In fact, we think (not just in BRT-BSBR, but in all Business Rules Group development) that there are risks in assuming, or trying to enforce, a specific methodology.

Similarly, we have kept BRT-BSBR independent of notation.  Various graphical notations can be used (including UML, of particular interest to the OMG), and we have used some for illustration in the submission.  But the model definition is in structured English.

BRT-BSBR: Community

At the top of the overview diagram is 'Community.'  This is our starting point.

The most important community for a BRT-BSBR is the business being modeled.  In our example, this would be EU-Rent, the car rental company.  It is a semantic community that shares understanding of a universe of discourse.  It is embedded within a wider semantic community -- that of people involved in the car rental industry -- from which it can adopt concepts and terminology.

Within the business being modeled there can be semantic sub-communities, such as the HQ people, the rental staff, the maintenance staff, and so on, who have their own, specialized extensions of the company’s universe of discourse.

Each semantic community contains one or more speech communities.  Each of these owns a vocabulary in which to express the universe of discourse.  Vocabularies are usually in natural languages but can also be constructed from artificial languages such as UML or XML.

BRT-BSBR:  Universe of Discourse

The universe of discourse contains three kinds of thing:  Concepts, Fact Types, and Guidance.  This reflects the 'Business Rules Mantra' mentioned in several Dispatches columns.  The version we use here is:  “Fact Types build on Concepts; Guidance builds on Fact Types."

This part of BRT-BSBR captures definitions of Concepts, Fact Types, and Guidance, independently of how those Concepts, Fact Types, and Guidance will be expressed -- what terms will be used, in what languages, etc.  Informally, within the project, we referred to this as the 'naked content' (although this did cause occasional problems with some partners’ employers’ email filters).

Concepts

Concepts correspond to things in the business, both tangible (like cars and people) and intangible (like car rental pricing group and car body style).

Concepts can be defined:

• Specifically within the business.

  For example, EU-Rent has the concepts of a 'bad experience' during rental (damage to car, moving traffic offence etc.) and 'barred driver' (someone with enough bad experiences that EU-Rent will not accept them, even as an additional driver on someone else’s rental).  Definitions can be supplemented by informal descriptions and examples.

• By adoption from a wider semantic community.

  For example, EU-Rent adopts industry standard definitions for 'rental,' 'collision damage waiver,' and many others.  We adopted many concepts (including the concept of 'concept') from ISO-1087-1 when we were developing BRT-BSBR.  Instead of a definition, there is a reference to the source of adoption.

• By direct naming of real-world individual things, where they are needed.

  For example, 'US Dollar,' 'Convertible' (as a car body style), 'Switzerland.'  Note that most individuals don’t appear in the vocabulary.  You wouldn’t have vocabulary entries for every EU-Rent car and every EU-Rent customer -- they will be modeled as data in the information systems built to support EU-Rent’s business.  But some individuals -- small predefined populations of things such as rental pricing groups, car body styles, countries, currencies -- are needed to define fact types and to build rules.  There is an analogy here with ‘reference data’ in database design.

Fact Types

Fact types define connections between concepts.  For example, 'car model is in rental pricing group,' 'car is rented by customer from pick-up branch at pick-up date/time to return branch at return date/time.'

Fact types can be ‘nominalized’ as concepts.  For example, the 'car is rented by customer from …' fact type (above) can be nominalized as 'rental' and then used in other fact types, e.g., 'car is assigned to rental.'

Guidance

We identified the need for two kinds of guidance -- business rules and clarifications.  Both are based on fact types.

Business rules are obligations, e.g.,

• “[it is obligatory that] renter has valid driver’s licence."
• “[it is obligatory that] not (renter has more than one rental with ‘open’ status)."

They are usually expressed in more business-friendly forms -- but that’s handled in 'Form of Expression.'

In a perfect world, clarifications would not be necessary.  In practice, they are helpful to support two important principles:

• Rules should be applied as the business intended.
• Only the rules owned by the business can be applied.

People in businesses may misunderstand rules, or assume rules that don’t exist.  Clarifications can help, e.g., 'Renter may book more than one rental.'  There is no rule to prevent this; however, there is a rule that a person cannot have more than one car at a time physically on rental.  EU-Rent created this clarification because there was an operational problem caused by some staff misapplying this rule.

BRT-BSBR:  Form of Expression

Our intention is to support expression of a business’s Universe of Discourse (the 'naked content') in different languages -- and also to support its expression in different ways in the same language.  Form of expression has two aspects:  vocabulary and statements made in that vocabulary.

Vocabulary

Each semantic community contains one or more speech communities.  Each speech community has a vocabulary in a language (usually a natural language like English or German, but it could be an artificial language such as UML).  The speech community uses its vocabulary to express its semantic community’s universe of discourse.

A vocabulary may include adopted vocabularies, such as ISO standards (for example, we used ISO-1087-1 in BRT-BSBR’s own vocabulary) and glossaries from industry groups, and we expect that most business vocabularies built on BRT-BSBR probably will.

A speech community’s vocabulary contains all the symbols the community agrees to use.  Most symbols are words and phrases in the vocabulary’s language, but they could be graphics or sounds.  They are in two categories:  terms and connecting symbols.

Terms represent 'naked' concepts, which correspond to things in the business.  The BRT-BSBR model supports synonyms (multiple terms for the same concept) and homonyms (the same term used, in different contexts, for different concepts).  Different groups of people in a business often use their own, local terminology; this is particularly the case when businesses merge, or are acquired, or enter into close working collaborations.  BRT-BSBR needs to support such local variation.

We know, from long experience in the Business Rules Group, that use of standard terminology cannot be enforced.  It can be encouraged.  So BRT-BSBR supports designation of some terms as 'preferred,' but if people in a business are using synonyms and homonyms they will continue to do so.  If the vocabulary does not support the synonyms and homonyms, some of the language in the business will not be captured in the shared vocabulary, and ambiguity and misunderstanding will increase.

Connecting symbols are the 'verb phases' used in expressing fact types; for example, the underlined phrase in 'renter is contractually responsible for rental.'  Different connecting symbols for the same 'naked' fact type are supported, to allow different representations of the fact type, e.g., 'rental is contractual responsibility of renter.'

Statements

BRT-BSBR supports three categories of statement: Definitions, Fact Statements, and Guidance Statements.

Definitions support the 'naked' concepts.  They can be formal (expressed in symbols in the vocabulary), or in informal natural language.  Where concepts have been adopted, there are references to the source vocabularies, e.g., industry glossaries or dictionary entries; the definitions can be copied in, if required.  Definitions can be supplemented by descriptions and examples.

Terms are connected to definitions indirectly, via 'naked' concept.  This means that it is easy, for example, to adopt a definition from an external source, but use a different term for it within the business, or to change the preferred term for a concept without any effect on the definition of the concept.

Fact statements express 'naked' facts in various ways, using the symbols in the vocabulary.

Guidance statements express business rules and clarifications.  As mentioned above, 'naked' business rules are obligations based on fact types.  Business rules can be expressed in three forms:

• Obligatory, e.g., 'It is obligatory that an intoxicated person is not accepted for a walk-in rental.'

• Prohibitive, e.g., 'It is prohibited that an intoxicated person is accepted for a walk-in rental'

• Conditionally permissive, e.g., 'A person may be accepted for a walk-in rental only if he/she is not intoxicated'

Less stilted forms are also supported, e.g., 'An intoxicated person must not be accepted for a walk-in rental.'  As an aside, note that the rule in these examples is one that will not be implemented in an IT system; it will be applied by people in EU-Rent.  BRT-BSBR handles all business rules uniformly, regardless of whether or not they could be or will be automated.

Clarifications have two forms.  The direct form is a 'Please remember that …' kind of statement.  For example, 'At the end of a rental, the car may be dropped off at any EU-Rent branch.'  (EU-Rent’s rationale is that it wants its car back.  If the branch is not the return branch named in the rental contract, EU-Rent can make a penalty charge -- but it wants its car back).

The pre-emptive form is more emphatic, e.g., 'A branch cannot refuse to accept a rental drop-off because it is not the designated return branch.'  This reads like a rule, but is actually a reminder that there is no EU-Rent rule that justifies such a refusal.

BRT-BSBR:  Logical Formulation

'Naked' content gets to its forms of expression via logical formulation.  Expression is business-friendly, is (usually) in natural languages, and uses the syntax and conventions of those languages.

Logical formulation lies below the surface of natural language expression.  It provides a formal, language-independent syntax.  As well as providing formal structure below the surface, this also supports representation in tools for portability and for transformation to IT specifications.

The basic building block is the atomic formulation, based directly on a 'naked' fact type.  There is then a full set of logical capabilities to build up propositions and apply modality to propositions.  The modalities explicitly recognized are Deontic (obligation, prohibition, permission), Alethic (necessity, possibility), and Epistemic (knowledge).  But BRT-BSBR is extensible, so additional modalities can be added, and we shall no doubt add some by the time we have developed the submission to its final form.

BRT-BSBR:  Formal Logic

'Naked' content and logical formulation are supported by formal logic, essentially first-order predicate logic with some extensions.

We examined various schemes for categorizing business rules and settled on pragmatic application of deontic logic as the best approach.  Deontic logic’s three forms -- permission, obligation, and prohibition - are highly intuitive for business people when defining and discussing business rules.  In fact, only permission and obligation are needed formally -- prohibition is captured as 'It is obligatory that it is not the case that ….'  We also needed the alethic operators 'It is necessary that' and 'It is possible that,' and the epistemic operator 'It is known that.'

Apart from standard modal operator transformations involving negation, no other use is made of modal logic theorems, so there was no requirement to choose any one out of many specific modal logics for a given modality.

The current BRT-BSBR model does not yet cater for interrogatives; for example, 'of the available cars of the requested car group, the one with the lowest odometer reading' which could be used for making the assignment of a car to a rental.  The necessary ‘hooks’ have been put in place to support interrogatives in the final submission.

BRT-BSBR: MOF/XMI

The Meta-Object Facility (MOF) is an OMG-supported standard, based on a subset of UML, for describing metamodels.  XML Metadata Interchange for MOF (XMI) is a related standard that defines how to export/import MOF-modeled metadata descriptions in XML.  Several implementations of MOF/XMI are available in repository services.

One of the BSBR deliverables required by the OMG is a UML model, rendered in XML.  This will ensure that BSBR (meta)models will be portable.

We have addressed this requirement by defining a mapping of BRT-BSBR to MOF.  The BRT-BSBR model, defined in structured English, will be imported by a MOF service.  Then, via XMI, an XML rendition will be generated.  This is not yet fully implemented, but it will be in time for our final submission.

However, as described above, BRT-BSBR is an extensible model.  The ‘vocabulary + rules’ for a specific business (such as EU-Rent) will be developed as an extension of BRT-BSBR, not as something distinct from it.  The same MOF/XMI mapping will support XML rendition of such a business-specific BRT-BSBR model, so that it can be:

• exchanged with other companies as a business description -- both vocabulary and rules,
• input to automatic transformations for IT system specifications.

In fact, the MOF/XMI mapping can also be used for XML rendering of business facts (e.g., 'John Hall rented car AJ 31256 from Zurich on 12 February 2004') for a business whose vocabulary and rules are defined in a BRT-BSBR model.  So, database content should also be exchangeable -- although this is outside the scope of the proposals requested by the OMG.

Conclusion

BRT-BSBR is clearly an important step for the Business Rules Group, which now has to move forward on two fronts.  It has to continue its role in the Business Rules Team, helping the OMG to realize Business Semantics of Business Rules as a useful, usable standard and as a foundation for sound, practical methodology and good supporting tools.

The BRG must also continue in its independent role, leading development in other areas of business rules.  Three high priority areas are:  business rule management; business rules and business process; business rules and workflow.

Our experience in BSBR has been very positive, and we hope to take part in future collaborations.

What Next?

The Business Rules Team submitted its first response on January 12, 2004.  The Team now has until end of July 2004 to develop the proposal further, taking account of responses from the OMG membership.

IBM and Fujitsu also made submissions.  The three proposals are different; we hope that we can collaborate, rather than compete, and get the best from all three.

If your company is an OMG member, have a look at the proposals.^[2]  If your company would like to endorse the one from the Business Rules Team, let me know and I’ll ensure that it’s added to the list of supporters.

And keep reading Dispatches for updates.

References

[1] Request for Proposal from the Object Management Group (OMG) on Business Semantics of Business Rules, available at: http://www.omg.org/cgi-bin/doc?br/03-06-03

[2] For OMG members, proposals for Business Semantics of Business Rules (plus other information on this activity) are available at: http://www.omg.org/techprocess/meetings/schedule/Bus_Semantics_of_Bus_Rules_RFP.html

# # #