SBVR: The Common Knowledge Language and The Most Promising Alternative in IT
Introduction
The European Council decided in Lisbon in March 2000 "to become, by 2010, the most competitive and dynamic knowledge-based economy in the world, capable of sustainable growth with more and better jobs...."[2] "The European Council in Spring 2006 did not attempt to hide the fact that, six years after its launch, the results of the Lisbon process have been mixed."[2] The author can't hide the fact that he would have preferred to see the two words 'euphemistically speaking' added after the word 'mixed'. Semantics of Business Vocabulary and Business Rules (SBVR) — the standard recently finalized by the OMG[15] — could be a major tool in accomplishing this EU-goal, if SBVR is introduced as Common Knowledge Language.
The transition from the Roman numeral system to that of decimal numbers brought about a major advancement of science and technology in Western Civilization. In a similar vein, our knowledge-based society is now as much in need of an effective representation of structured knowledge.
In this article we stress that SBVR is not only useful in business as its name could erroneously imply, but in many other areas, such as education, economics, banking, insurance, social security, law, governance rules, government, and IT. In the next column we will furthermore describe and illustrate three essential aspects of SBVR that are much more useful than usually described:
- The elementary fact,
- The fact type reading, and
- The concept definition.
Each of these three is required to productively base the business rules upon. Ron Ross formulates it as follows: "[...] rules build directly on terms and facts."[16] In the next column we will present the core of a repeatable process to specify the fact types and fact type readings, as well as the most important structural rules.
1. The Wider Application Area of SBVR
The name 'SBVR' — Semantics of Business Vocabulary and Business Rules — could easily give the wrong impression on the wider applicability of SBVR. SBVR can fruitfully be applied in business and business rules. It has, however, a much, much wider application area than suggested by the awkward name.
SBVR contains a sufficient number of sound concepts that makes it the best candidate to become the de-jure or de-facto standard structured knowledge description language. This is the landmark aspect of SBVR. "SBVR is a landmark for the OMG, the first OMG specification to incorporate the formal use of natural language in modeling and the first to provide explicitly a model of formal logic."[10] SBVR could become for many subject areas like education, training, law, finance, governance, and government services what mathematics has become for the sciences and technology in the past century. Why is SBVR the best candidate for the Common Knowledge Language?
A. Natural Language Based
A fact model in SBVR "[…] is represented by a set of sentences, each of which connotes either a rule or a ground fact. The fact model may be fully automated (as in, say, a database system), manual (as in, say, a paper record system), or semi-automated. The knowledge may even be stored in human memory (belonging to the business domain experts who may be collectively regarded as the authoritative source of those business facts that are of interest). However, the knowledge must ultimately be expressible by sentences communicated between humans."[15] In a future article/column in the Business Rules Journal we will illustrate the various common and different aspects of ground facts and rules.
At the Semantic Technology Conference in 2007 Donald Chapin said it as follows: "To fully exploit the reasoning power of the Semantic Web sooner rather than later, subject matter experts need to be able to record their knowledge in as natural and familiar a way as possible — in the way they already think about their knowledge; i.e., natural language. The OMG's new Semantics of Business Vocabulary and Business Rules (SBVR) standard provides the connection between vocabularies, definitions, natural language grammar, and formal logic."[4]
In IEEE Software we read: "The US Bureau of Labor Statistics estimates that nearly 70 percent of the 136 million employees in the US non-farm workforce were engaged in some form of information work at the turn of the 21st century."[6] SBVR provides the opportunity to be used as a common knowledge language by these 100 million employees. This could have a dramatic positive effect on productivity. The widespread introduction of SBVR as the Common Knowledge Language requires a major effort in developing educational and training material for various groups of employees. How many people have the vision that the development of such material is in all probability as important for the knowledge economy as developing educational material to acquire calculating skills? SBVR could be used as a new base subject in the knowledge economy, say Knowledgatics 101, in which analysis, specification, communication, and validation are treated in a fully integrated way. Integration is a major aspect of the knowledge economy, as opposed to the stovepipes of the industrial age.
B. Formal
In IT, far too many times the statement has been made that natural language was unsuitable as a precise language. This was, and probably is, a popular statement at many Computer Science departments and conferences. Nothing could be further from the truth. Montague has published excellent material to support the opposite. "Montague's thesis is that there is no essential difference between the semantics of natural language (like English) and formal languages (like predicate logic)."[12] The author has practiced this thesis for over 35 years and will share his experiences in this journal. The author gives a very warm welcome to SBVR as it is a formal subset of natural language. "A fact model is a conceptual model of the business domain, using a suitable high level vocabulary and language that is readily understood by the business domain experts. Typically this language will be a formal subset of a natural language."[15]
C. Formal Logic
"SBVR has a sound theoretical foundation of formal logic, underpinning both logical formulation and the structures of bodies of shared meanings. The base is first-order predicate logic (with some restricted extensions into higher-order logics), with some limited extensions into modal logic [...]."[15] This in itself will give SBVR a prominent place in the knowledge economy.
D. Automatic Development: No Further Need to Off-Shore the Programming of Code
SBVR is the result of a unique cooperation between logicians, semanticists, linguists, and business analysts. "Logicians, semanticists, and linguists provide the logical, mathematical, and linguistic capabilities that make it possible to transform business vocabularies and rules from the business perspective to PIM [Platform Independent Model] and PSM [Platform Specific Model] information systems designs, to structure a variety of natural language statements into SBVR constructs, and to verbalize SBVR entries into any number of natural language statements."[15]
Hence SBVR makes it a reality to have the business persons specify the complete business process requirements in their preferred language and subsequently generate the information system. This is for IT principally the same step forward as the step from assembler programming languages to higher level programming languages in the sixties and seventies. Of course there was quite a bit of resistance at the time in the IT programming community. The arguments against the current step forward can be shown to be false with the same kind of reasoning applied successfully in the seventies. "L'histoire se repete (toujours)." The elimination of traditional IT programming will result in a major step forward in productivity in the knowledge economy. Full business process descriptions expressed in a SBVR compatible language can be used as input for web application generation. This is a new generation in the productivity development.
In Hall 2004 we read: "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."[7]
When it comes to software productivity far too much emphasis is given to the subject of code. A typical example can be found in Groth: "[…] our customers continue to tell us of dramatic increases in productivity. [...] For example, one [...] went from 80 to 280 developers in two years and effectively managed four million lines of code."[6] Please remember in last month's column one can read: "The concept definition of low productivity is: 'doing with maximum efficiency what should not be done at all'."[14]
As long as we expressed our numbers using Roman numerals we had difficulty seeing the possible productivity improvement when using decimal numbers. Numbers of lines of code is the wrong issue; a solid SBVR-based methodology, understood by all stakeholders, to develop SBVR-based business requirements, quantification of requirements, and subsequently generating the code is the issue. Furthermore, as long as code gets nearly all the attention we will keep repeating the same errors.
By investing optimally in requirements by consistently using SBVR we can make use of an undisputed law in IT: "There is a compelling case to be made that the identification of software defects earlier in the development cycle is the quickest way to make developers more productive."[3] By applying a best practice process for developing SBVR specifications (the subject of several future columns) and detecting errors at the earliest possible time by making complete and accurate specifications validated by the people in the know, it is possible to completely eliminate the vast majority of coding problems.
In his book Business Rules and Information Systems, Tony Morgan describes the problem very clearly:
It is clear that the total costs of our inability to produce software in a well-ordered way runs into hundreds of billions of dollars per year, and the figure is growing. Countless efforts have been made over the past 30 years or more to fix various parts of the process. Although these efforts may have helped to contain the problem, they obviously haven't solved it. This leaves a lingering suspicion that maybe it's the process itself that's fundamentally flawed.
Our current development culture puts a huge emphasis on programming, and the popular perception is that 90% percent of building an information system relies on the cleverness of the coders. Several Hollywood movies have perpetuated the myth by featuring teenaged hackers as their heroes.
As always, the reality is different. Many research projects have shown that the vast majority of software problems originates from specification error, not from the code as such. Put it simply, the programmers are programming the wrong things, and no amount of cleverness in the coding can compensate.
Frustratingly, few people seem to care. The number of books published on programming is orders of magnitude greater than books on analysis and specification. We seem to just keep on doing the same things in the blind hope that it will come out right next time, but unless we address the root causes of the problems, there's no rational reason why it ever should.
The biggest problem of all is the industry mindset. We won't make real progress until we're brave enough to challenge some fixed ideas on 'this is the way it's done'. This means opening the door to new ways of thinking and being willing to reengineer the development process if there's a promising alternative.[11]
It is my professional opinion that SBVR, coupled with an effective and efficient development process or best practice methodology, is the most promising alternative.
"SBVR is positioned to be entirely within the business model layer of the OMG's Model Driven Architecture (MDA)."[15] Cummins makes an interesting statement on the EDS blog: "[…] MDA is about solving problems working at a higher level of abstraction. It is just the beginning of a new era where, not only will most application programmers no longer write code, but we will solve new classes of problems […]."[5]
SBVR opens the possibility to introduce more flexibility by removing not only the constraints from the application code. Another candidate is the specification in SBVR of authorizations.[1]
E. Concept Definitions as First Class Citizens
"Data by itself is not enough — what we really need is information, the meaning or semantics behind the data."[9] One of the best steps forward in SBVR is to have concept definitions as first class citizens. Lack of concept definitions is a major source of problems in the IT approaches used thus far. Of course, concept definitions consist of a combination of formal and informal aspects. This bridge is the basis for effective communication.
2. The Development of Best Practices or a Methodology for SBVR
There is a need for a methodology to develop a complete SBVR structured knowledge description, bi-directionally traceable from the first document through all intermediate results to the final result, in an optimal combination of diagrammatic and textual format that combines various aspects, such as:
- being repeatable,
- easily learnable by subject domain experts,
- using an understandable subset of natural language,
- having been used extensively and resulted in best practices and
- processes with built in quality control.[13]
Subject domain experts probably use a similar number of constructs as formal mathematicians, but use everyday symbols and language. Hence there is a need to develop a comprehensive methodology that includes the formal operations in a way acceptable to a subject domain expert.
In [8] we read:
"A typical business person:
- does not talk about quantifications — but expresses quantifications in almost every statement he makes.
- doesn't talk about conjuncts, disjuncts, negands, antecedents and making consequents — but these are all part of the formulation of his thinking.
Logical formulation of Semantics is about explicitly using these conceptual devices (that people use unconsciously all the time) to capture the semantics of their discourse."
This is a major challenge.
References
[1] Baisley, Don, Unisys Rules Modeler, Presentation at European Business Rules Conference 2007.
[2] Europa, Europe in 12 lessons, Lesson 8: Towards a knowledge-based society, URL: http://europa.eu/abc/12lessons/lesson_8/index_en.htm
[3] Campara, Djenana, "Developing secure software is a management issue," Computerworld, URL: http://www.computerworld.com/securitytopics/security/story/0,10801,104127,00.html
[4] Chapin, Donald, Progress Report on Using SBVR Structured English to Generate OWL Models, 2007 Semantic Technology Conference, San Jose, California, May 2007.
[5] Cummins, Fred, Models: Key to Future Business Survival, EDS' Next Big Thing Blog, URL: http://www.eds.com/sites/cs/blogs/eds_next_big_thing_blog/archive/2006/04/13/8543.aspx, 2006.
[6] Groth, Robert,"Is the Software Industry's Productivity Declining?" IEEE Software, November/December 2004.
[7] Hall, John, "Business Semantics of Business Rules," Business Rules Journal, Vol. 5, No. 3 (Mar. 2004), URL: http://www.BRCommunity.com/a2004/b182.html
[8] Hall, John, Semantics of Business Vocabulary and Business Rules (SBVR), presentation at the BPM Think Tank, Arlington, VA, 23 May 2006.
[9] Halpin, Terry, Information Modeling and Relational Databases, Morgan Kaufmann, San Francisco (2001).
[10] Hendryx, Stan, "SBVR and MDA," Business Rules Journal, Vol. 6, No. 10 (Oct. 2005), URL: http://www.brcommunity.com/a2005/b253.html
[11] Morgan, Tony, Business Rules and Information Systems: Aligning IT with Business Goals, Addison-Wesley, Boston (2002), p. 5.
[12] Montague Grammar, Wikipedia entry, URL: http://en.wikipedia.org/wiki/Montague_grammar
[13] Nijssen, Sjir, A Framework for Discussion. In: ISO/TC97/SC5/WG3 and comments on 78.04/01 and 78.05/03 (1978).
[14] Nijssen, Sjir, "SBVR: Semantics for Business," Business Rules Journal, Vol. 8, No. 10 (Oct. 2007), URL: http://www.BRCommunity.com/a2007/b367.html
[15] OMG, Semantics of Business Vocabulary and Business Rules (SBVR), First Interim Specification, Mar. 2006. Available as dtc/06-03-02 at http://www.omg.org, Clause 10.1.1.2, Annex A.3.5, Annex A.4.4.
[16] Ross, Ronald, Business Rule Concepts, Getting to the Point of Knowledge, BRSolutions LLC (2005), p. 24.
# # #
About our Contributor:
Online Interactive Training Series
In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.