Since our meeting of the OMG Business Rules Working Group in New Orleans (Nov. 2002), there has been a steady tide of emails on the BusinessRules mailing list.  One helpful thread has been a discussion about where business rules fit in the OMG’s scheme of models.  In this article, I summarize where I think we are with this discussion, particularly with respect to business modeling.

A Business Model is a precise description of the business, by the business, in business language, for business purposes.  A model may take the form of text, tables, or graphics, or a combination of them, and has an underlying formalism that enables machine reading.  Different purposes may require different models, so we need to understand up front our purpose for building a business model.  These are some business purposes that have been identified for the business modeling technology contemplated by the BRWG:

• Provide organized knowledge about business policies, processes, events, organization, information, locations, and system requirements needed to support specific system development or integration projects, to bridge business to IT.
• Aid analysis, design, and optimization of business processes and organization separate from systems projects.
• Provide source material to help educate and train company personnel, partners, agents, and customers on how the business operates.

Since the mission of the OMG is to set standards for systems, the major focus of the OMG BRWG is, not surprisingly, on the first point above.  Having said that, the BRWG is striving to make the business modeling capability it specifies as general as possible, to suit other (non-system) purposes without compromising the focal mission.  The business model is increasingly seen as having significant intrinsic value to the business, apart from its role with the IT department.  Here are some key system development goals the BRWG business model is intended to support:

• Provide a formal basis for specifying the business requirements for the system.
• Provide a means for business people to efficiently and effectively validate system designs for conformance to the requirements.
• Provide authentic instructional and training material for system users.
• Aid system development by automated transformation of the business model and the requirements into components of the system, in accordance with software architecture and systems architecture requirements.

These lists of purposes and goals are not closed.  If any of you would like to suggest additions or changes to the lists, please feel free to do so, by sending your comments to me.

The OMG’s Model Driven Architecture divides models into three categories that separate system development concerns to promote quality, efficiency, and reuse:

1. Computational Independent Business Models (CIM),
2. Platform Independent Models (PIM), and
3. Platform Specific Models (PSM).

Each category has a principal audience of authors and readers.

The CIM is the business person’s modeling sandbox.  Business people are the principal audience of the CIM.  There has been considerable discussion about what content should or should not be in the CIM, and how the CIM should be organized.

The consensus appears to be that the CIM should not be defined in any way to limit what business people can say in the CIM, regardless of how much of a computational flavor it may or may not have.  Business process charts, business arithmetic, business formulae, and business decision tables ... all are always fair game in the CIM, to describe business terms, business facts, business processes, business events, business organization, business locations, and business policies.  It is the intent of the CIM to include only factors of business concern, be they computational or otherwise, including pure business models and business requirements for systems.  Gratuitous computational modeling in the CIM is discouraged.  Business people can include in their business models those specific system technical requirements that they feel they have a business reason to specify.  If IT thinks the business people have gone overboard in including computational factors as business concerns, IT needs to negotiate that with the business people, and then the CIM needs to be updated to reflect the resolution.

The CIM is seen as being organized into three main sections:

• Business Model,
• Business Requirements for the System, and
• System User Interaction Requirements.

The Business Model is a “pure” business model, devoid of system considerations (unless they are also business considerations).  Definitions of business terms, facts, and rules are ubiquitous in the Business Model.  The scope of the Business Model in a CIM must, at a minimum, include the business functions served by the system being specified. 

The Business Requirements for the System contains the contract between the business and IT about what the business expects the system to do, in precise terms.  This is where it is described what parts of the business the system automates, exactly. 

The System User Interaction Requirements describe the details of use cases, including data presentation and navigation requirements, and look-and-feel standards, but leave out user interface technical details.  In the CIM, screen shots are discouraged as excessive, at least before the system is built.

It was stated above that the business model was by the business, in business language.  An important goal of BRWG business modeling specifications is to find ways for business people to describe the business model in their own language.  This means natural language (e.g., 'structured English') and business graphics (like process flow charts and tables).  It is hoped that tools based on BRWG standards will, to a large extent, be usable by non-technical business people to build or maintain their own business models.  Analysts are still expected to work with business people to develop their business models.

I will discuss the appearance of business rules in the PIM and PSM in subsequent articles.

# # #