Business and IT often speak a different language.  Although both are talking about similar concepts, they do so with different purposes, different meanings, and different levels of detail.  SBVR is a successful endeavor to unite both visions as it allows for using a language that is understandable by the business, and yet precise and complete enough to be used for IT systems.  Experience with such a language has shown the positive results in business practice.

The Semantics of Business Vocabulary and Business Rules (SBVR) is an approach to business modeling that, on the one hand, provides a number of conceptual vocabularies for modeling a business domain and a set of rules.  On the other hand, it fully describes the semantic structure and meaning of expressions that can then be used in information systems.

Business Communication

Business knows what it is talking about but does not have the language to express it unambiguously.  Complex diagramming facilities, formal notations, etc. are not the language of the business.  English (or any other natural language) is — but long text is not precise enough and usually not complete.  It is the merit of SBVR to allow a complete and precise specification of business concepts, facts, and rules without any reference to IT or IT terminology ... and doing so in a set of statements that are easily understood by all stakeholders, including the business people.  The SBVR specification defines a structured, English vocabulary for describing vocabularies and verbalizing rules, presented in a language called SBVR Structured English.  But this could be any natural language, like French, German, or Chinese.

Business has to set the limitations of what is possible, necessary, permissible, and obligatory.  Setting these specifications right, and without any ambiguity, will ensure that information systems will behave as expected and will continue to do so if the business reality changes.  It also allows communicating unambiguously, not only between business and IT, but also within the business, between departments, management levels, partners in the value chain, etc.

Communicating with IT

It is up to the business to decide about rules, exceptions, results, constraints — but these have to be communicated clearly.  The details of calculations, rules, and decisions should not be left to system implementers or hidden away inside systems.  But this means that the specifications should be "practically perfect in every way."  It also means that changes in the business reality need to be easily related to parts of the information systems (i.e., traceability and impact analysis).

Moreover, an information system will implement an instance of a solution that falls within the totality of the business rules, but that should not be a reason to throw away the original rules and constraints.  When the information system changes, it still has to continue to support the underlying business constraints, so these need to remain available.  All too often a solution is put in place reflecting an underlying restriction that has not been made explicit, meaning that restriction may later be unknowingly overlooked when the system is changed.  A business rule might (for example) state that tasks A and B should never be performed by the same person.  In the original design this constraint might be satisfied, but many alterations and optimizations later the rule might be discarded because no one remembered.  It is important that the rules of the business are, and remain, explicit.

What else do we need?

Having a standard is fine, but we need two other things to make it fully operational:

On the business side:  tools, practices, and examples to allow business users to use the vocabulary correctly — tools for modeling, verification, validation, visualization, and management of SBVR specifications in the form of definitions and rule statements.  And additional vocabulary might be useful, e.g., for declaratively expressing process-related concepts, events, and process rules, and for handling violations of behavioral rules.

On the IT side:  architectures to move from SBVR models to straightforward implementations.  That is what the OMG’s model driven architecture (MDA) is all about.

Although business rules always cost the business something (Article 8.3 of the Business Rules Manifesto), clear communication within and between the business and IT sides is where we find a major return on rules.

Let the games begin!

# # #