SBVR thoughts
I spent two days last week to study the Semantics of Business Vocabulary and business Rule or SBVR specification. SBVR is part of the OMG’s Model Driven Architecture (MDA) with the goal to capture specifications in natural language and represent them in formal logic so they can be machine-processed. It includes two specialized vocabularies:
* Vocabulary for Describing Business Vocabularies which deals with all kinds of terms and meanings.
* Vocabulary for Describing Business Rules which deals with the specification of the meaning of business rules, and builds on top of the previous vocabulary.
The meanings are declined into concepts, questions and propositions. The meaning is what someone intends to express or understands. A phrase such as "We deny the invoice if the medical treatment was done after one year of the accident" has a clear meaning for a claim processor within a car insurance company. Analysts need to transform logically this meaning into concepts which has a unique interpretation so that they can represent the business knowledge within a comprehensive vocabulary and rules.
Business rules are declined into two possible classes:
* Structural (definitional) business rule which are about how the business chooses to organize the things it deals with, they are considered as necessity. In this context the statements describing the rule can describe the necessity, the impossibility or the restricted possibility.
* Operative (behavior) business rule govern the conduct of business activity. They are considered as obligation and directly enforceable. When considering operative business rule it is important to look at the level of enforcement to specify the severity of action imposed by the rule in order to put or keep it in force. Statements to describe the rule include obligation, prohibition, and restricted permission.
In SBVR, rules are always constructed by applying necessity or obligation to fact types. Fact type is an association between two or more concepts.
SBVR is defining a complete grammar to specify business logic. I was thinking it may be too complex to get easily accepted by the field, even if it may been seen as mandatory when moving to an extended SOA: There is a need to define enterprise ontology, to avoid reinventing the definition of terms used by all the services deployed in the SOA.
From a project management perspective SBVR brings interesting risks as the project team members may engage in a huge effort of documentation, without delivering working software. Not so agile, this stuff. The just good enough should be kept in mind and a build by increment for this conceptual model may be a good approach.
The second important risk will be linked to the size of the universe we have to cover. Defining all the vocabulary and business policies for a given business application will generate a lot of facts and rules that may be implemented in different environments or not implemented at all. Then the decision to select which rule goes where, will add time to the project.
I had in mind to use a sub part of SBVR to help control the way we harvest rule during the discovery and analysis activities, but use it only in the context of what need to be implemented. The next ABRD drop for the end of the month will propose things around that.
Any comments are welcome.
* Vocabulary for Describing Business Vocabularies which deals with all kinds of terms and meanings.
* Vocabulary for Describing Business Rules which deals with the specification of the meaning of business rules, and builds on top of the previous vocabulary.
The meanings are declined into concepts, questions and propositions. The meaning is what someone intends to express or understands. A phrase such as "We deny the invoice if the medical treatment was done after one year of the accident" has a clear meaning for a claim processor within a car insurance company. Analysts need to transform logically this meaning into concepts which has a unique interpretation so that they can represent the business knowledge within a comprehensive vocabulary and rules.
Business rules are declined into two possible classes:
* Structural (definitional) business rule which are about how the business chooses to organize the things it deals with, they are considered as necessity. In this context the statements describing the rule can describe the necessity, the impossibility or the restricted possibility.
* Operative (behavior) business rule govern the conduct of business activity. They are considered as obligation and directly enforceable. When considering operative business rule it is important to look at the level of enforcement to specify the severity of action imposed by the rule in order to put or keep it in force. Statements to describe the rule include obligation, prohibition, and restricted permission.
In SBVR, rules are always constructed by applying necessity or obligation to fact types. Fact type is an association between two or more concepts.
SBVR is defining a complete grammar to specify business logic. I was thinking it may be too complex to get easily accepted by the field, even if it may been seen as mandatory when moving to an extended SOA: There is a need to define enterprise ontology, to avoid reinventing the definition of terms used by all the services deployed in the SOA.
From a project management perspective SBVR brings interesting risks as the project team members may engage in a huge effort of documentation, without delivering working software. Not so agile, this stuff. The just good enough should be kept in mind and a build by increment for this conceptual model may be a good approach.
The second important risk will be linked to the size of the universe we have to cover. Defining all the vocabulary and business policies for a given business application will generate a lot of facts and rules that may be implemented in different environments or not implemented at all. Then the decision to select which rule goes where, will add time to the project.
I had in mind to use a sub part of SBVR to help control the way we harvest rule during the discovery and analysis activities, but use it only in the context of what need to be implemented. The next ABRD drop for the end of the month will propose things around that.
Any comments are welcome.
Comments