We need more SBVR

February 2009

OMG’s SBVR (Semantics of Business Vocabulary and Business Rules) is one of those initiatives that we love at EDDC4IT. SBVR is all about specifying the business vocabulary and the business rules.

In short, the vocabulary consists of terms (noun concepts) and facts. Facts are relationships between one or more terms, for example: “a member borrows a book”. These are actually referred to as “facttype” rather than “facts”. A fact is an instance of a facttype: “Jennifer borrows SBVR for Dummies”.

For years we have watched with amazement how IT was “forced” to take care of these two business aspects (just as with the business process models). Business rules are often modelled alongside the system requirements, and the defining the vocabulary becomes a task of the analyst by using domain modelling (aka conceptual modelling) from scratch.

In shaping the SOA the vocabulary is often used to identify and specify the services and components that offer them. Components are assigned the responsibility of a group of related business concepts (these relations are visible through the modelling of facttypes). The SOA suffers when the business architecture does not include this semantic model. The SOA is defined by an enterprise wide body (often referred to as service portfolio planning), and not by individual projects. When we need to rely on a project’s domain model to shape the SOA, we have a problem (this means the SOA is shaped very incrementally: it needs projects to be shaped-this might lead to a badly shaped SOA as you lack information when shaping it. Reshaping is not an option as it leads to breaking existing contracts between service providers and its consumers.

It is so important for the SOA (let alone the benefits already for IT: using MDA you should be able to transform SBVR (MOF compliant) into a first cut domain model using UML (which leads to a class model).