The Emergence of SBVR and the True Meaning of "Semantics" Why You Should Care (a Lot!) ~ Part 2
by Ronald G. Ross
The official debut on December 11, 2007 of the new standard Semantics of Business Vocabulary and Business Rules (SBVR 1.0) proves that business semantics for machines is a solvable problem and viable approach. Mark that date! An important threshold was passed for our industry. Let me explain why.
Top-5 List of Reasons Why SBVR for Software
Now that SBVR is a reality, what software opportunities does it open up? Why is SBVR such a milestone for the industry? Here's my list of top-5 reasons.
Tools can now eliminate human involvement in the translation of business intent into running code.[1] They will permit you to automate your business rules on whatever platform (current or next generation) deemed most suitable. Since the semantics are captured comprehensively in completely platform-independent, language-free fashion, they can be taken in any direction that tool-builders support (and with provably consistent business results). Business logic is now truly liberated from programming.
Tools can now support automatic translation between different natural languages (as long as you have foundation vocabularies for each of the languages). That's no small thing in a global economy.
Tools can now help you determine automatically whether you and your suppliers and/or customers are literally 'speaking the same language'. Better yet, tools will support inter-company delivery and receipt of knowledge packets for automatic, near-real-time set-up of operational business interactions.
Tools can now automate the operational aspects of contracts, deals, and agreements of all sorts (unfortunately not eliminating lawyers though). As above, they will support automatic, near-real-time set-up of new operational business engagements.[2] They will also support manageable customization of products and services as a business proposition on a scale never before possible.
Tools can now test your business logic comprehensively for anomalies (e.g., conflicts) before you ever deploy or distribute it, or even commit it to development on any specific platform(s).
Top-3 List of Reasons Why You Should Move to SBVR Work Practices Now
My top-5 list above talks for the most part about 'futures'. So why you should make an immediate move into SBVR-based work practices? What's in it for you today? Here's my top-3 list. It's all about smarter ways of doing the everyday work of business analysis.
You need to retain business know-how (i.e., your in-depth rules for how business is conducted) in a business-friendly, precise-but-non-technical form. You need your operational business knowledge to be explicit, rather than tacit. Your company runs the risk of losing key people. You need a pragmatic approach to knowledge retention.
You business doesn't really know what its business rules are. It can't directly put its fingers on them in order to reengineer some business process(es), redeploy decision logic to some new platform(s), demonstrate how you are complying with regulatory statutes or contractual obligations, etc. You need a better way to manage and disseminate business rules consistently across various parts of the organization.
You need to develop operational decision logic and other kinds of shared, knowledge-rich specifications directly with business people in business terms. You have found that use cases don't work very well for that. You need to improve communication between the business and IT and support a better, more business-friendly front end for your requirements process.
I summarize the impact of SBVR this way: It literally provides the gateway to the knowledge economy for every kind business (not just those on the web). If you're guessing I will be talking a lot more about the coming of the knowledge economy in future columns, you'd be exactly right.
References
[1] This has already been demonstrated by Unisys's Rules Modeler, the reference implementation for SBVR. Incidentally, SBVR by no means eliminates all involvement by IT professionals in software affairs. Platform-specific deployment specifications and performance tuning, for example, will still be required. It should also be noted that SBVR in no way substitutes for business process or workflow capabilities. SBVR simply removes the need for translating business rulesinto software.
[2] I was tempted to include a similar item in my top-5 list about large-scale, automatic delivery and receipt of laws and regulations from governmental and other regulatory bodies. It's certainly feasible — and probably inevitable. But it may be slow in coming for reasons that have little to do with technology.
standard citation for this article:
Ronald G. Ross, "The Emergence of SBVR and the True Meaning of "Semantics: Why You Should Care (a Lot!) ~ Part 2," Business Rules Journal, Vol. 9, No. 4
(April 2008), URL: http://www.BRCommunity.com/a2008/b409.html
Ron is recognized internationally as the "father of business rules." He is the author of ten professional
books including the groundbreaking first book on business rules The Business Rule Book in 1994.
His newest are:
Ron serves as Executive Editor of BRCommunity.com and its flagship publication,
Business Rules Journal. He is a sought-after speaker at conferences world-wide. More than 50,000 people have
heard him speak; many more have attended his seminars and read his books.
Ron holds a BA from Rice University and an MS in information science from Illinois Institute of Technology.
For more information about Mr. Ross, visit www.RonRoss.info, which hosts his blog. Tweets: @Ronald_G_Ross
Ronald G. Ross is Principal and Co-Founder of