Ron Ross was kind enough to send me a copy of his recently publishd 3rd edition of his book, Business Rule Concepts.\u00a0 Ron has been at the forefront of mainstreaming business rule capture for decades.\u00a0 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).\u00a0 This book is an indispensible backgrounder and introduction to the concepts necessary to effectively manage business rules using this standard.<\/p>\n
By no means is this a book about SBVR.\u00a0 Rather, it is about the core and critical concepts necessary to understand how\u00a0 to define an enterprise repository of declarative knowledge covering business.\u00a0 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.\u00a0 Essentially, my problem with much of the increasingly mainstream marketing and practicing of business rules is precisely the term “rule”.\u00a0 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).<\/p>\n
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.\u00a0 Veterans will quickly recognize and benefit from the simple clarity that Ron brings to the subject.<\/p>\n
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.\u00a0 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.<\/p>\n
Although Ron and I have come to a shared view on knowledge capture and management, we have followed different paths.\u00a0 Ron’s concern is primarily capture.\u00a0 Mine extends to and necessarily emphasizes implementation and execution.\u00a0 Nonetheless, our perspectives on modeling and capture are extremely aligned.\u00a0 Ron’s writing on what he calls “terms” and “wordings” are right on the money.<\/p>\n
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.\u00a0 In effect, Ron argues and I agree that the knowledge is much more important, durable, and valuable than its executable form or expression.\u00a0 As a result, I could not more emphatically introduce Ron’s coverage of how to express models and logic in English.<\/p>\n
By the end of Chapter 1, Ron defines what he calls a vocabulary and why\u00a0 managing\u00a0 vocabulary is a requirement for managing business knowledge (including definitions, requirements, and policies).\u00a0\u00a0 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.<\/p>\n
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.\u00a0\u00a0 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.\u00a0 For example, wordings like “a person has an age” seem arcane, perhaps technical, to me.\u00a0 Nonetheless, even though my work supports such “phrasings”, most of its users still use “has” phrasings!\u00a0 Perhaps this is because I have not taken the time and expended the effort to clarify the concepts that Ron covers so well.\u00a0 In short, Ron’s writing is right on target for practitioners given the current state of the art (and standards).\u00a0 And I can think of no other expert or author who has reduced current practice to such an accessible form.<\/p>\n
Chapter 4 clearly explains and motivates the use of sentences as the independent units of business knowledge.\u00a0 Ron does a good job of introducing the notion of roles as the components linked together within predicates using verbs.\u00a0 This is fairly abstract material, so I don’t blame him for avoiding too much depth on the semantics of roles.\u00a0 Fortunately, other materials, such as the SBVR standard itself, cover these details in greater depth.\u00a0 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”.<\/p>\n
Ron clearly separates statements defining and relating concepts from requirements.\u00a0 Not only does he present the material linguistically, he reinforces it with clear graphical presentations of the corresponding models.\u00a0\u00a0 Personally, I prefer to mix certain requirements with definitions, as in “a person has exactly one mother”, \u00a0but this would complicate the graphical presentations.\u00a0 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.\u00a0 Otherwise, the models become unnecessarily complex or the resulting sentences seem cumbersome, if not stilted.<\/p>\n
In places the formality of SBVR shows through.\u00a0 For example, “a person must not lease a vehicle the person owns”.\u00a0 This reflects linguistic limitations of available tools.\u00a0 This phrasing reflects “necessity” within the underlying logical formalism of SBVR.\u00a0 In addition, the reiteration of “the person” begs for natural language processing that would understand pronouns, such as “(s)he”.\u00a0 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.\u00a0 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.<\/p>\n
Having encountered the notion of logical necessity in the preceding example, it is worth pointing to Ron’s discussion in Chapter 10.\u00a0 Externalizing business knowledge from systems requires certain architectures for information systems.\u00a0 For example, the prohibition of a person leasing a vehicle that (s)he owns requires some action not stated here.\u00a0 In effect,\u00a0 a violation of requirements must be anticipated in the runtime architecture.\u00a0 There are various approaches to this, including runtime exceptions.\u00a0\u00a0 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).\u00a0 More advanced approaches, such as meta-reasoning, and detailed architectural approaches are appropriately left out of this work on capture and management.<\/p>\n
Interestingly, in Chapter 7, Ron suggests that business rules should not be expressed within an if-then syntax.\u00a0 Obviously, this clearly separates Ron’s methodology from the production rule focus of most commercial BRMS.\u00a0 It also exposes a gap between SBVR and operational systems.\u00a0 Ron discusses behavioral rules within the chapter but the gap between requirement and behavior remains unfilled.\u00a0 This is my most significant concern for the logical approach to knowledge management.\u00a0\u00a0 Without a framework by which declarative knowledge can bridge to imperative action, the logical approach falls short of operational relevance.\u00a0 This is reflected, in my practical viewpoint, by the lack of operational deployment of SBVR.<\/p>\n
The principal\u00a0 challenge remaining for SBVR is to cross the gap from expression into operation.\u00a0 Aside from linguistic limitations, this is my primary concern for the formal logic approach to knowledge capture and management.\u00a0\u00a0 The ideas Ron covers so well are necessary for long-term success in automating managed knowledge, but they are not enough.\u00a0\u00a0 Unfortunately, most of the business rule vendors do not adequately address the necessary capabilities that Ron’s methodology and toolsets handle.\u00a0 This leaves us with a continuing need for business rule engineers to bridge the gap, manually.<\/p>\n","protected":false},"excerpt":{"rendered":"
Ron Ross was kind enough to send me a copy of his recently publishd 3rd edition of his book, Business Rule Concepts.\u00a0 Ron has been at the forefront of mainstreaming business rule capture for decades.\u00a0 Personally, I am most fond of his leadership in establishing the Object Management Group’s Semantics of Business Vocabulary and Rules … <\/p>\n