Ron Ross was kind enough to send me a copy of his recently publishd 3rd edition of his book, Business Rule Concepts. Ron has been at the forefront of mainstreaming business rule capture for decades. Personally, I am most fond of his leadership in establishing the Object Management Group’s Semantics of Business Vocabulary and Rules standard (OMG’s SBVR). This book is an indispensible backgrounder and introduction to the concepts necessary to effectively manage business rules using this standard.
By no means is this a book about SBVR. Rather, it is about the core and critical concepts necessary to understand how to define an enterprise repository of declarative knowledge covering business. The unfortunately reality is that the work necessarily suffers from legacy concepts and perspectives, but this is a statement of fact and practicality rather than a negative assessment. Essentially, my problem with much of the increasingly mainstream marketing and practicing of business rules is precisely the term “rule”. Nonetheless, since the mainstream audience is pre-occupied with the word “rules” rather than the word “knowledge”, Ron’s book is – again – right on the money for practitioners who want to achieve the benefits of separating models and knowledge from implementations in order to increase the agility of systems and more closely align IT with business needs (all of which he discusses in Chapters 2 and 3).
This edition clearly benefits from the progress in the field and reflects current enterprise objectives that have progressed into the mainstream since Ron began practicing and writing many years ago. Veterans will quickly recognize and benefit from the simple clarity that Ron brings to the subject.
The critical topics that Ron addresses are the core concepts underlying modeling and linguistics that allow non-technical business analysts (even, perhaps, subject matter experts) to capture unambiguous statements of business definitions, requirements, policies and other “rules” in English sentences that are suitable for presentation to and verification by stakeholders. In addition, in the event knowledge-level standards like SBVR evolve and are adopted by technology (e.g., business rule) vendors, managing such statements will directly impact the operational behavior of business processes, especially where they involve automated decisions, policy enforcement and other forms of governance requiring enforcement.
Although Ron and I have come to a shared view on knowledge capture and management, we have followed different paths. Ron’s concern is primarily capture. Mine extends to and necessarily emphasizes implementation and execution. Nonetheless, our perspectives on modeling and capture are extremely aligned. Ron’s writing on what he calls “terms” and “wordings” are right on the money.
We have independently arrived at a point where we believe that linguistic expression of business knowledge is much more important (and valuable) than rule-based expressions suitable for execution by rule engines. In effect, Ron argues and I agree that the knowledge is much more important, durable, and valuable than its executable form or expression. As a result, I could not more emphatically introduce Ron’s coverage of how to express models and logic in English.
By the end of Chapter 1, Ron defines what he calls a vocabulary and why managing vocabulary is a requirement for managing business knowledge (including definitions, requirements, and policies). Ron’s writing on nouns and verbs and how they form the backbone of expression for business knowledge is seminal and accessible to novice and expert practitioner alike.
As more of an artificial intelligence practitioner, I might quibble with the omissions of mass nouns, such as money or time, from his discussion, but these topics will not be missed by anyone but the most forward-looking strategist. Similarly, the limitation of current standards to wordings involving verbs eliminates coverage of adjectival phrases and results in too many wordings involving the verb “has”, at least in my opinion. For example, wordings like “a person has an age” seem arcane, perhaps technical, to me. Nonetheless, even though my work supports such “phrasings”, most of its users still use “has” phrasings! Perhaps this is because I have not taken the time and expended the effort to clarify the concepts that Ron covers so well. In short, Ron’s writing is right on target for practitioners given the current state of the art (and standards). And I can think of no other expert or author who has reduced current practice to such an accessible form.
Chapter 4 clearly explains and motivates the use of sentences as the independent units of business knowledge. Ron does a good job of introducing the notion of roles as the components linked together within predicates using verbs. This is fairly abstract material, so I don’t blame him for avoiding too much depth on the semantics of roles. Fortunately, other materials, such as the SBVR standard itself, cover these details in greater depth. So again, the content seems right on for someone entering the field and focused on linguistic modeling, capture and management rather than more formal “semantics”.
Ron clearly separates statements defining and relating concepts from requirements. Not only does he present the material linguistically, he reinforces it with clear graphical presentations of the corresponding models. Personally, I prefer to mix certain requirements with definitions, as in “a person has exactly one mother”, but this would complicate the graphical presentations. He also addresses common linguistics, such as passive voice and using verbs (i.e., participles) as adjectives, which I have found to be important concepts that must be brought to practitioners’ attention. Otherwise, the models become unnecessarily complex or the resulting sentences seem cumbersome, if not stilted.
In places the formality of SBVR shows through. For example, “a person must not lease a vehicle the person owns”. This reflects linguistic limitations of available tools. This phrasing reflects “necessity” within the underlying logical formalism of SBVR. In addition, the reiteration of “the person” begs for natural language processing that would understand pronouns, such as “(s)he”. Having said that, this is clearly a higher level statement than can currently be understood and implement by most business rule management systems (BRMS), however. As such, it demonstrates the power of Ron’s approach and motivates (given most commercial offerings) the separation of capture and management of business knowledge from its expression in business process management systems (BPMS) or BRMS.
Having encountered the notion of logical necessity in the preceding example, it is worth pointing to Ron’s discussion in Chapter 10. Externalizing business knowledge from systems requires certain architectures for information systems. For example, the prohibition of a person leasing a vehicle that (s)he owns requires some action not stated here. In effect, a violation of requirements must be anticipated in the runtime architecture. There are various approaches to this, including runtime exceptions. Ron demonstrates this approach in Chapter 10 and, if the system incorporates workflow for resolution, he advocates using the end-user accessible form of business knowledge for explanation (in his discussion of guidance within Chapter 2). More advanced approaches, such as meta-reasoning, and detailed architectural approaches are appropriately left out of this work on capture and management.
Interestingly, in Chapter 7, Ron suggests that business rules should not be expressed within an if-then syntax. Obviously, this clearly separates Ron’s methodology from the production rule focus of most commercial BRMS. It also exposes a gap between SBVR and operational systems. Ron discusses behavioral rules within the chapter but the gap between requirement and behavior remains unfilled. This is my most significant concern for the logical approach to knowledge management. Without a framework by which declarative knowledge can bridge to imperative action, the logical approach falls short of operational relevance. This is reflected, in my practical viewpoint, by the lack of operational deployment of SBVR.
The principal challenge remaining for SBVR is to cross the gap from expression into operation. Aside from linguistic limitations, this is my primary concern for the formal logic approach to knowledge capture and management. The ideas Ron covers so well are necessary for long-term success in automating managed knowledge, but they are not enough. Unfortunately, most of the business rule vendors do not adequately address the necessary capabilities that Ron’s methodology and toolsets handle. This leaves us with a continuing need for business rule engineers to bridge the gap, manually.
Hi Paul,
Good to see you blogging again. I looked at SBVR a few years back when Said Tabet mentioned it. Like you, I have a lot of concerns over the “practical” aspects of it. For me, the SBVR approach is too laborious. A lot of the nouns can be automatically generated from a business model or object model. The verbs, pronouns and adjectives also can be auto-generated. The approach said and I used in the past was to create a Natural Language mapping framework, which is more powerful than SBVR and less labor intensive.
peter