Issue 9477: The current notion of "actionable" falls short in several regards (sbvr-ftf) Source: Microsoft (Mr. Don Baisley, donbaisley(at)live.com) Nature: Uncategorized Issue Severity: Summary: The current notion of "actionable" falls short in several regards: * It does not take into account structural (definitional) rules. * Its wording is based on "complying", which is only appropriate for operative (behavioral) rules. * It fails to address the issue of lexical indexicals -- conversational references to person, place and time. The attached document (SBVR-Actionable-pp138+178.doc) reflects the detail of the proposed revision. Resolution: see above Revised Text: Replace Figure 12.1 on page 137 with the following: (note that this diagram incorporates changes introduced in the resolution to Issue 9444) (source file provided separately as: Issue 9477 Fig12.1 CatGdnc.eps within dtc/2006-09-03) In 12.1.1 on page 138 delete the entire entry for "directive": In 12.1.1 on page 138 delete the entire entry for "directive is actionable": In 12.1.1 add this entire entry for "element of guidance is practicable": element of guidance is practicable Concept Type: characteristic Definition: the element of guidance is sufficiently detailed and precise that a person who knows the element of guidance can apply it effectively and consistently in relevant circumstances to know what behavior is acceptable or not, or how something is decided or calculated Dictionary Basis: able to be done or put into practice successfully; able to be used, useful [ODE] Note: The sense intended is: "It's actually something you can put to use or apply." Note: The behavior, decision or calculation can be that person's own. Note: Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. Note: A practicable business rule is also always free of any indefinite reference to people (e.g., "you", "me"), places (e.g., "here"), and time (e.g., "now"). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to "tell" time), and (b) external clarification. In 12.1.1 add this entire entry for "element of governance": element of governance Definition: element of guidance that is concerned with directly controlling, influencing or regulating the actions of an enterprise and the people in it Dictionary Basis: conduct the policy, actions, and affairs of (a state, organization, or people) with authority: control, influence, or regulate (a person, action, or course of events) [ODE, "govern"] In 12.1.1 add this entire entry for "element of governance is directly enforceable": element of governance is directly enforceable Definition: violations of the element of governance can be detected without the need for additional interpretation of the element of governance Concept Type: characteristic Note: 'Directly enforceable' means that a person who knows about the element of governance could observe relevant business activity (including his or her own behavior) and decide directly whether or not the business was complying with the element of governance. Necessity: Each element of governance that is directly enforceable is practicable. Necessity: An element of governance that is not directly enforceable is not practicable. In 12.1.1 on page 138 modify the entry "business policy" as follows: 1. Replace the current Definition with the following: Definition: element of governance that is not directly enforceable whose purpose is to guide an enterprise 2. Replace the current Note with the following: Note: Compared to a Business Rule, a Business Policy tends to be: - less structured - less discrete or not atomic - less carefully expressed in terms of standard vocabulary - not directly enforceable. 3. Leave the Dictionary Basis unchanged. 4. Add the following Necessity: Necessity: No business policy is a business rule. 5. Add the following 4 Examples: Example: The policy expressed as "A prisoner is considered to be on a hunger strike after missing several meals in a row." Example: The policy expressed as "The prison medical authority will intervene if a hunger striker's life is in danger." Example: The EU-Rent policy expressed as "Rental cars must not be exported." Example: The policy expressed as "Each customer who complains will be personally contacted by a representative of the company." In 12.1.1 on page 138 for the entry "element of guidance" remove the Definition and Necessity captioned items, and add the following 4 captioned items so that the entire entry reads: element of guidance General Concept: proposition Definition: means that guides, defines or constrains some aspect of an enterprise Note: This sense of 'means' (as in 'ends and means', rather than 'is meant as') arises from the Business Motivation Model [BMM]. Note: The formulation of an element of guidance is under an enterprise's control by a party authorized to manage, control or regulate the enterprise, by selection from alternatives in response to a combination of assessments. In 12.1.1 on page 138 replace the entire entry "element of guidance is based on fact type" with the following: proposition is based on fact type Definition: the proposition is formulated using the fact type Example: The EU-Rent business rule that is expressed as "It is obligatory that each rental specifies a car group." (or, in RuleSpeak, "A rental must have a car group.") is based on the EU-Rent fact type 'rental specifies car group'. In 12.1.1 on page 139 for the entry "body of shared meanings includes body of shared guidance" add the following Synonymous Form: Synonymous Form: body of shared guidance is included in body of shared meanings In 12.1.1 on page 139 for the entry "body of shared guidance includes element of guidance" add the following Synonymous Form: Synonymous Form: element of guidance is included in body of shared guidance Place the resulting entries of 12.1.1 in the following order: body of shared guidance body of shared meanings includes body of shared guidance body of shared guidance includes element of guidance element of guidance element of guidance is practicable element of governance element of governance is directly enforceable business policy proposition is based on fact type In 12.1.2 on page 139 for the entry "rule" replace the current Definition with the following: Definition: proposition that introduces an obligation or a necessity Note that this entry ("rule" ) is also being changed under Issue 9579. The net of the changes from these issues will result in the removal of the current 3 Dictionary Basis items, the addition of a new Dictionary Basis item, and (here) the above, updated Definition. As a result of both Issues, the entry for "rule" will read: rule Definition: proposition that introduces an obligation or a necessity Dictionary Basis: one of a set of explicit or understood regulations or principles governing conduct or procedure within a particular area of activity… a law or principle that operates within a particular sphere of knowledge, describing or prescribing what is possible or allowable. [ODE] In 12.1.2 on page 139 for the entry "business rule" add the following General Concept item, following the current Definition: General Concept: rule, element of guidance In 12.1.2 on page 139 for the entry "structural business rule" add the following Necessity item, following the Synonym: Necessity: Each structural business rule is practicable. In 12.1.2 on page 139 modify the entry "operative business rule" as follows: 1. Update the 1st Definition to read: Definition: business rule that is intended to produce an appropriate or designed effect and is directly enforceable 2. Delete the 2nd Definition. 3. Update the 3rd Definition to read: Definition: business rule that there is an obligation concerning conduct, action, practice or procedure within a particular activity or sphere 4. Add a new Definition (after the above) that reads: Definition: element of governance that is directly enforceable 5. The 2 Dictionary Basis items are unchanged. 6. The 2 Necessity items are unchanged. 7. Add a new Necessity (after the current 2) that reads: Necessity: Each operative business rule is directly enforceable. 8. The Synonym is unchanged. In 12.1.3 on page 139 remove the first 3 words from the Definition for the entry "level of enforcement" so that the Definition now reads: Definition: a position in a graded or ordered scale of values that specifies the severity of action imposed in order to put or keep an operative business rule in force In 12.1.4 on page 140 replace the current Definition for the entry "admonition" so that the Definition now reads: Definition: element of guidance that is practicable and that is a proposition that there is not an obligation or necessity where, by custom or practice, one might be assumed In 12.1.4 on page 141 remove the first Necessity from the entry "admonition". In 12.1.4 on page 141 after the last Necessity for the entry "admonition" add the following 2 Necessities: Necessity: No business policy is an admonition. Necessity: No business rule is an admonition. In 12.1.4 on page 141 replace the current Definition for the entry "affirmation" so that the Definition now reads: Definition: element of guidance that is practicable and that is a proposition that there is a permissibility or possibility where, by custom or practice, one might not be assumed In 12.1.4 on page 141 remove the first Necessity from the entry "affirmation". In 12.1.4 on page 141 after the last Necessity for the entry "affirmation" add the following 2 Necessities: Necessity: No business policy is an affirmation. Necessity: No business rule is an affirmation. On PDF pages 178-179, replace section A.2.3.3 with the following three sections. (Note that the second section is a slightly modified version of the last two paragraphs of the original A.2.3.3.) A.2.3.3 What 'Practicable' Means All business rules (and affirmations and admonitions as well) need to be practicable. Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. Because an operative business rule is practicable, a person who knows about it can decide directly whether it is being followed when that person observes relevant behavior. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. If a structural rule is practicable, a person who knows about it can also decide directly whether it is being followed when that person observes some relevant outcome from a decision or calculation. A practicable business rule is also always free of any indefinite reference to people (e.g., "you", "me"), places (e.g., "here"), and time (e.g., "now"). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to "tell" time), and (b) external clarification. All these criteria assume that the person understands the business concepts that underlie the business rule. A practicable business rule always imparts ready-to-apply knowledge of the kinds above 'on top' of such concepts. An important best practice for business rules, following naturally from this, is that the underlying business vocabulary/ies must be well developed and well managed. Specifically, each business concept should: o Be individually well defined. o Fit logically into the overall structure of concepts. o Made available to the person in appropriate manner. In addition, each business rule should be directly expressible in the given business vocabulary/ies. These best practices point toward the essential role of business vocabularies in supporting business rules - indeed, the bulk of SBVR is devoted to that area. A.2.3.4 Business Rules that Cannot Be Automated Just because business rules are practicable, this does not imply they are always automatable. Many business rules, especially operative business rules, are not automatable in IT systems. For instance, consider the obligation example given above, "A Customer who appears intoxicated or drugged must not be given possession of a Rental Car." This distinction is not important within SBVR, which focuses on rules only from the business perspective, regardless of whether the rules could be automated. However, it is obviously important in defining a transformation from business model to PIM. In particular, non-automatable business rules need to be implemented as user activity, supported by procedure manuals or rulebooks. A.2.3.5 What 'Directly Enforceable' Means All operative business rules need to be directly enforceable. To be enforceable, an operative business rule has to be defined in such a way that violations can be detected. The enforcement regime can then detect a violation and take appropriate action (e.g., correct the violation, notify other parties, and/or impose penalties on the violators). Elements of governance directly govern what people do in the business, and they need to be enforceable. Being directly enforceable is what distinguishes business policies from operative business rules. The importance of this is that when the people specifying a business encounter (or need to define) elements of governance in the real world, they need to think about two things. First, is the element of governance directly enforceable - i.e., is it possible to observe what people are doing, and recognize whether they are complying or not, without needing further amplification or explanation of the element of governance? If it is not, then the element of governance is a business policy and those who are defining the business haven't yet finished. They also need to develop operative business rules, derived from the business policy, that are are directly enforceable. For example, the EU-Rent element of governance 'rental cars must not be exported' is not sufficiently precise to be enforced. It is a business policy and needs operative business rules through which it can be enforced. For example: o Each rental car must be registered in the country of the local area to which it is assigned after purchase. o The country of registration of a rental car must not be changed. o If a car is at a location outside its country of registration, it may be assigned only to a rental with return location in its country of registration. o If a rental car is at a location outside its country or registration for more than five days, it must be returned to its country of registration. Second, if an element of governance is directly enforceable, it ought to be derived from a business policy. If it is not, the business designers ought to be aware that this is so (and might choose to question whether the rule is appropriate). Actions taken: March 27, 2006: received issue April 26, 2010: closed issue Discussion: Make separate fact types for 'is practicable' and 'is actionable'. Rearrange the generalization hierarchy in 12.1 to better represent commonly understood usage of terms. Add further explanation to Annex A. End of Annotations:===== iler: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Mon, 27 Mar 2006 20:52:39 -0600 To: Juergen Boldt From: "Ronald G. Ross" Subject: Issue for SBVR - re: "Actionable" Cc: keri , "Baisley, Donald E" Juergen, We are jointly posting this issue for SBVR. Thanks, Ron ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Name: Semantics of Business Vocabulary and Business Rules Specification Doc: dtc/06-03-02 Date: March 2006 Version: Interim Convenience Document Chapter: Chapter 12 [12.1.1] and Annex A [A.2.2.3] Page: p. 138 and 178 Nature: Enhancement Severity: Moderate Description: The current notion of "actionable" falls short in several regards: * It does not take into account structural (definitional) rules. * Its wording is based on "complying", which is only appropriate for operative (behavioral) rules. * It fails to address the issue of lexical indexicals -- conversational references to person, place and time. The attached document (SBVR-Actionable-pp138+178.doc) reflects the detail of the proposed revision. Submitted by: Ronald Ross Don Baisley Keri Anderson Healy SBVR - Actionable - p138 + p178.pdf Date: Mon, 03 Apr 2006 06:40:38 -1000 From: John and Keri Subject: Re: issue 9477 -- SBVR FTF issue To: John Hall , "Ronald G. Ross" , SBVR-FTF Thread-topic: issue 9477 -- SBVR FTF issue Thread-index: AcZXPVZalLR9HsMwEdqDCgARJM+Cgg== User-Agent: Microsoft-Entourage/11.2.1.051004 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k33GVcbq028568 On 4/2/06 6:00 PM, "John Hall" wrote: > Hello all, > ... > Issue 9477 > ... > Then I looked up the submitters on the OMG web site, and moderated my > language for Thursday's meeting. If .loony¹ bruised tender feelings, > then I apologize. It was an apparently unsuccessful attempt to express > humorously my surprise that this proposal had come from within the FTF. > Although it did get a laugh at the time (not included in the draft > minutes). ... John, Thanks for sharing your perspective on this Issue. I'm going to be offline for a bit (probably missing this week's meeting) and won't have time to give a detailed response to your note. However, I've given it a quick look and it's clear that we have a difference of substance on our interpretation of 'actionable' -- what it means and the role it plays in the big picture, and I would like to get a quick note 'on the record' to express my position. >From my perspective, our submission didn't stretch the definition of 'actionable' -- it reflects what 'actionable' has always been and we were simply tidying up some wording. Going back to the earlier days of our BMM work, I have always emphasized the dual connection we made there between element of guidance and *both* the means and the ends components. In fact, my personal take (which probably isn't shared with process zealots) is that the 'desired result' (ends) is where the more effective guidance occurs (i.e., the link between element of guidance and desired result, reflected in BMM). From my perspective, this is where 'actionable' plays a role on the 'definition' side of the house. It has always been that way to me -- no change to stretch anything there. Things qualify to be in a population (or not) based on whether the thing 'fits' the criteria outlined in the definition. Can I measure/assess some desired result? When the criteria are clear/unambiguous that ability for a thing to be classified correctly and consistently by any/all humans moves the element of guidance beyond being fuzzy policy (i.e., sense of 'actionable' as relates to ends). When things are correctly/clearly in populations, other things happen (or not) to/with them. In some cases, things 'move' in and out of populations as they meet (or don't) the defined criteria, making them eligible (or not) for other rules to apply. Back in the day, when I was writing the 'unruly rules' stories, some of my best came from rules/laws that attempted to enforce operative guidance written against fuzzy definitions (ugly signage rules, anti-fast food restaurant laws, porch furniture bans, etc., etc.). If I had time, I could write more compelling prose but this rough thumbnail will hopefully give you a sense of where I am coming from on 'actionable' clearly needing to stay in place, as we have it in SBVR. In conclusion, I don't know where I fit in Ron's 'looney' set -- clearly, he hasn't shared with us his 'actionable' definition ... and as a wise fellow, hopefully he won't share. (hahaha, my weak contribution to the humor side of this issue). For this week's meeting, ... Enjoy, - Keri X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 06 Apr 2006 13:27:31 -0500 To: john.hall@modelsys.com, SBVR-FTF From: "Ronald G. Ross" Subject: Re: "Actionable" Issue X-Server: High Performance Mail Server - http://surgemail.com At 11:30 AM 4/6/2006, John Hall wrote: Ron, Sorry - a bit of shorthand because it was a summary. Your proposal said: .Whether or not some element of guidance is actionable is decided with respect to what a person with legitimate need can understand from it. ... For a structural business rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others.. If you don.t understand what the criterion .has flown at least 25000 qualifying miles in the preceding calendar year. means (and that includes understanding what .qualifying mile. means), you don.t know what a gold flyer is. Let me ask you this. Suppose next year (for whatever reason) the criterion is changed to .has flown at least 25001 qualifying miles in the preceding calendar year.. Are you saying that the fundamental notion/essence (and definition) of "gold flyer" has changed? Of course not. Otherwise, we will have a very hard time communicating in the business from one year to the next. The essence of "gold flyer" is something like "customer who flies a considerable amount and is therefore given some special treatment". The exact criteria can change -- that's why they should be intentionally *separate* from the definition (as rules). This is not only fundamental to the business rules approach, but a highly pragmatic approach to the challenge of managing change. If you want a *full* understanding of "gold flyer", you always need both the definition and the *rules* (criteria). The rules (criteria) alone cannot give you the essence of the notion. After all we are trying to support real person-to-person (not just machine-to-machine) business communication. Also, you need to understand what the more general concept .member of the frequent flyer program. is - if you don.t know what its definitional criteria mean, then you don.t know what a gold flyer is. If you don't understand the definitional criteria, you don't understand the definition. So, even though you have stated it indirectly, I read your proposal as extending the meaning of actionable to include "understanding what a definition means". Knowing what a gold flyer is doesn.t require any action. .Actionable. is about what the enterprise in question - in this case, the airline - does. The kinds of action the airline takes include: - record the qualifying miles flown (if we concern ourselves here with information system actions) - permit gold flyers with coach tickets to check in at the first class desk - give gold flyers upgrade credits for each 10,000 miles flown The notion of "actionable" in SBVR (and in the BRG before that) has always been synonymous with "practicable": [MWUD]: 1 : possible to practice or perform : capable of being put into practice, done, or accomplished 2 a : capable of being used : USABLE The sense that you are trying to project for "actionable" ... that it is somehow tied to overt action ... is just not what "actionable" has been about. In fact, it should *not* be tieed to anything else besides rules (directives) because that is outside the scope of rules in general, and SBVR in particular. But, as I said, I.ll propose an alternative only if there is some support in the FTF for my view. If there isn.t, I.ll back off for SBVR, and the OMG can deal with it when SBVR needs to be integrated with other business models - BMM, BPDM, OSM, compliance models (when they appear). This should not be an issue. The notion of "actionable" has been carefully crafted all along *not* to overspill the boundaries of business rules. So there can be no impact into these other areas, and therefore no need for concern. The underlying issue is that structural business rules are part of definitions. They belong in the concepts and vocabulary that provide a common base for all the business models. If you look at business process (BPDM) and organization responsibility (OSM) - both about action, by the way - as well as business rules, two things are clear: 1) The other models need to share the definitions - including the criteria embodied in structural business rules Somehow SBVR has managed to avoid using "structural rule" in building any of its own vocabularies. How could it possibly be that SBVR has managed to do that, but these other models/vocabularies would not be able to do so?!? The notion is incomprehensible to me. 2) It should be possible to integrate the 3 models fairly cleanly, because a major objective is that they shouldn.t interact very much. We should be able to change business rules and rules-sets without restructuring the business processes that they enable (and vice versa), and to reassign organization responsibilities independently of changing the rules or the internal workings of business processes. So we.d be hoping for a limited set of associations to get a workable integration. You would need to explain more clearly how anything that SBVR has done has limited the ability to accomplish those goals. Frankly, I am at a loss to see any manner in which SBVR has sone so. In other words, we should have (at least) three not-too-tightly coupled .doing. models, with a shared .knowing. model - the set of concept definitions. Again, explicit examples would be required because I do not find that SBVR has any current limitations in that regard. You you see them, then please, by all means, put them forward. Ron But this doesn.t show if we look only at SBVR. If the majority of the FTF prefer to look only at SBVR - and I accept that there are arguments for doing so - then I won.t hold us up by fighting this issue. In that case, I think we'd be leaving problems for others (or maybe some of us) in the future. . Regards, John Ronald G. Ross wrote: At 11:00 PM 4/2/2006, John Hall wrote: Hello all, Correction to draft minutes --------------------------- Issue 9477 I've attached my initial response to the issue and its proposed solution. If there is any support for my view, I'll produce the detailed editing instructions. John, I am happy to engage in a discussion on these matters. However, before doing so, a clarification please ... In your "Summary" (not "Basis of Counter-Proposal") you write: "Stretching SBVR's meaning of 'actionable' to include "understanding what a definition means" is not good way to resolve the issue." What do you mean? There is no mention of "Definition" in the substance of our write-up, nor any intent to mention that concept. So I can't ascertain out what you might be referring to(?). Thanks, Ron Best wishes, John X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 07 Apr 2006 15:37:59 -0500 To: john.hall@modelsys.com, SBVR-FTF From: "Ronald G. Ross" Subject: Structural Business Rules and Definitions [was formerly: "Actionable" Issue] X-Server: High Performance Mail Server - http://surgemail.com At 11:30 AM 4/6/2006, John Hall wrote: Ron, The underlying issue is that structural business rules are part of definitions. John, This is simply not the case, in SBVR, in MWUD, and in the way *business people* in the real world think and write. I would refer you to 3 relevant definitions in MWUD (see attached) for (a) Definition, (b) Rule, and (c) Criteria. In these definitions, you will find (a) that "rule" and "criteria" can be taken as direct synonyms (in the definitions relevant to business, business vocabulary and business rules), but (b) that "definition" is not indicated in any way as a synonym for either of the other two. Instead, "definition" focuses on "essential nature" -- essence (see highlighting). Here are the relevant quotes: "Definition" ... 2 : a word or phrase expressing the essential nature of a person or thing or class of persons or of things [bolding added] "Rule" ... b : a standard by which something is judged or valued : CRITERION [bolding added] "Criteria" ... 2 : a standard on which a decision or judgment may be based It's always good to remind ourselves who the primary (driving) audience for SBVR is -- *business people*. It's not professional terminologists (like ISO), not standards people (like OMG members), and not 'semantic programmers'. If there is any lingering haziness about these questions, we need to clear them up now, not only for the the sake of SBVR and any public discussion thereof, but also for any other models in OMG that might want to take advantage of SBVR for vocabulary purposes. We've got a spot-on approach in SBVR. Ron Definition - Rule - Criteria - from MWUD.doc X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 07 Apr 2006 12:39:19 -0500 To: John and Keri , SBVR-FTF From: "Ronald G. Ross" Subject: Re: "Actionable" Issue X-Server: High Performance Mail Server - http://surgemail.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k37HTogJ002941 Keri, Thanks, this helps a lot. Ron At 11:54 AM 4/7/2006, John and Keri wrote: On 4/7/06 6:27 AM, "Ronald G. Ross" wrote: >> At 10:04 AM 4/7/2006, Keri wrote: >> John, Thanks for so clearly showing us where you are coming from in your >> write-up. In some of what I read in your write-ups -- snippets below from >> you more recent -- I get a sense for your desire to be able to divide and >> distinguish. > > Keri (or John), > > I would like to get a better sense of 'divide and > distinguish' *what*? I can't say I am clear on > that from either what you wrote (above), or what > John wrote (below). Sorry if it's obvious. Ron, When I wrote "divide and distinguish" I was speaking broadly ... in the sense of what I see the role a discriminator characteristic doing (which is to divide, distinguish, and unify, at some level of categorization scheme). For example, where 'actionable is currently placed, it (a) divides (partitions) 'directive', (b) distinguishes things of the two categories at that level, and (c) unifies (on that trait) since all things of a category at that level share that characteristic value. So when John wrote that our proposal was "extending the meaning of actionable" I took it to mean that, for him, it wasn't serving as discriminator in the taxonomy in those ways, where it is. Perhaps somewhere else in the taxonomy (which I assume since I didn't read "throw it out" into his alternative) -- just not where it is, in the role it's playing there. That's all I meant. And in the bits I quoted (still below) I saw suggestions of different ways to cut the pie (different needs to "divide and distinguish" [and unify]). I saw wording that talks about where "structural rules ... belong in" and being able to have models "not-too-tightly coupled" as implying a need to make different cuts of the overall pie. And, since it was presented under the banner of this issue, I read into that a proposal that "actionable" should play a role somewhere else in making those cuts. But I could be very well wrong in that interpretation. John would need to clarify that aspect. ~ Keri > In my mind, we have clearly and cleanly divided > and distinguished 'business policy' and 'elements > of guidance' for pragmatic purposes (which is > what counts). I can report from the field that > the distinctions work ... BRS has been applying > them for the best part of 10 years now to dozens > and dozens of clients in North America and > Europe, and business people and analysts > inevitably 'get it' and like it. And I've never > seen anyone confused by the "action" portion of > the "actionable" signifier, or somehow misapply it on the process side. > > However, if something needs clearing up, let's > get 'on it' ... "actionable" is a key concept of > both the business rule approach and of rules in SBVR. > > Ron > >> Certainly we need to be able to do that. But I feel that we >> *can* already do that, in rich and varied ways. I'd just not like to use >> *this* concept to (also) accomplish that goal. >> >> hope this helps, >> - Keri >> >> On 4/6/06 6:30 AM, "John Hall" wrote: >>> ... >>> So, even though you have stated it indirectly, I read your proposal as >>> extending the meaning of actionable to include ... >>> >>> The underlying issue is that structural business rules are part of >>> definitions. They belong in the concepts and vocabulary that provide a >>> common base for all the business models. ... >>> >>> 1) The other models need ... >>> >>> 2) It should be possible to integrate the 3 models fairly cleanly, because >>> a major objective is that they shouldn¹t interact very much. ... >>> >>> In other words, we should have (at least) three not-too-tightly coupled >>> ³doing² models, ... Date: Fri, 07 Apr 2006 05:04:13 -1000 From: John and Keri Subject: Re: "Actionable" Issue To: SBVR-FTF Thread-topic: "Actionable" Issue Thread-index: AcZaVIfgxrsf+MZHEdqoJQARJM+Cgg== User-Agent: Microsoft-Entourage/11.2.1.051004 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k37Et1Bn015526 The one thing that jumps out is a difference in motivation about what the concept here is intended for. If we return to that perspective (focusing on the concept rather than the signifier --or signifier part) it may help. Where "is actionable" is positioned it serves to distinguish directives that are 'fuzzy' from those that are not. In the early days, that division was more basic (i.e., two-way) -- business policy (fuzzy) or 'not fuzzy' (which we could label 'business rule'). For varied reasons (not worth detailing here) we didn't pick 'fuzzy' to use in the signifier of the discriminator and opted for 'actionable' ... with a definition and explanation, because even back then it tended to evoke other, not-intended senses. As the richness on the 'not fuzzy' side evolved, the structure of it also evolved. And the term for the 'other half' of this level of the taxonomy became the rather bland (but not inaccurate) 'element of guidance' -- the non-fuzzy (i.e., 'actionable') notion -- and 'business rule' moved down in the taxonomy. And as the structure of concepts and terms grew richer, they had their own ways of being distinguished, one from another. Bottomline: the motivation for the concept under discussion here ('actionable') remains that of *unifying* everything that falls under it and to distinguish things of the concept at that level of generalization from those of its partner, 'business policy' -- the two categories of 'directive' in the segmentation being presented. If we retain that original motivation for the characteristic in question (the concept currently using 'actionable') then we appear to be faced with a binary choice: (1) retain 'actionable' and improve its explanation/definition so that the fact that 'action' appears within it does not conjure up the wrong picture (i.e., to be confused with 'execute' or 'automate' or the directive itself be something that is put into action) -or- (2) select some other signifier for this *unifying* discriminator -- say, 'moofbarkle', or In the writeup we submitted for this issue, we are taking approach (1) -- largely because (a) there is already a history of clarifying that it should not be so confused and we were simply trying to make that clarifying wording even better and (b) we haven't be able to come up with a better term (and 'moofbarkle' or some other non-baggage-carrying signifier is too much of a leap). John, Thanks for so clearly showing us where you are coming from in your write-up. In some of what I read in your write-ups -- snippets below from you more recent -- I get a sense for your desire to be able to divide and distinguish. Certainly we need to be able to do that. But I feel that we *can* already do that, in rich and varied ways. I'd just not like to use *this* concept to (also) accomplish that goal. hope this helps, - Keri On 4/6/06 6:30 AM, "John Hall" wrote: > ... > So, even though you have stated it indirectly, I read your proposal as > extending the meaning of actionable to include ... > > The underlying issue is that structural business rules are part of > definitions. They belong in the concepts and vocabulary that provide a common > base for all the business models. ... > > 1) The other models need ... > > 2) It should be possible to integrate the 3 models fairly cleanly, because a > major objective is that they shouldn¹t interact very much. ... > > In other words, we should have (at least) three not-too-tightly coupled > ³doing² models, ... X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 07 Apr 2006 11:27:58 -0500 To: John and Keri , SBVR-FTF From: "Ronald G. Ross" Subject: Re: "Actionable" Issue X-Server: High Performance Mail Server - http://surgemail.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k37GIHRa001628 At 10:04 AM 4/7/2006, John and Keri wrote: John, Thanks for so clearly showing us where you are coming from in your write-up. In some of what I read in your write-ups -- snippets below from you more recent -- I get a sense for your desire to be able to divide and distinguish. Keri (or John), I would like to get a better sense of 'divide and distinguish' *what*? I can't say I am clear on that from either what you wrote (above), or what John wrote (below). Sorry if it's obvious. In my mind, we have clearly and cleanly divided and distinguished 'business policy' and 'elements of guidance' for pragmatic purposes (which is what counts). I can report from the field that the distinctions work ... BRS has been applying them for the best part of 10 years now to dozens and dozens of clients in North America and Europe, and business people and analysts inevitably 'get it' and like it. And I've never seen anyone confused by the "action" portion of the "actionable" signifier, or somehow misapply it on the process side. However, if something needs clearing up, let's get 'on it' ... "actionable" is a key concept of both the business rule approach and of rules in SBVR. Ron Certainly we need to be able to do that. But I feel that we *can* already do that, in rich and varied ways. I'd just not like to use *this* concept to (also) accomplish that goal. hope this helps, - Keri On 4/6/06 6:30 AM, "John Hall" wrote: > ... > So, even though you have stated it indirectly, I read your proposal as > extending the meaning of actionable to include ... > > The underlying issue is that structural business rules are part of > definitions. They belong in the concepts and vocabulary that provide a common > base for all the business models. ... > > 1) The other models need ... > > 2) It should be possible to integrate the 3 models fairly cleanly, because a > major objective is that they shouldn¹t interact very much. ... > > In other words, we should have (at least) three not-too-tightly coupled > ³doing² models, ... Date: Fri, 07 Apr 2006 06:54:32 -1000 From: John and Keri Subject: Re: "Actionable" Issue To: "Ronald G. Ross" , SBVR-FTF Thread-topic: "Actionable" Issue Thread-index: AcZaY/EbL/L5gMZXEdqhrAARJM+Cgg== User-Agent: Microsoft-Entourage/11.2.1.051004 X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k37GjK8x002023 On 4/7/06 6:27 AM, "Ronald G. Ross" wrote: >> At 10:04 AM 4/7/2006, Keri wrote: >> John, Thanks for so clearly showing us where you are coming from in your >> write-up. In some of what I read in your write-ups -- snippets below from >> you more recent -- I get a sense for your desire to be able to divide and >> distinguish. > > Keri (or John), > > I would like to get a better sense of 'divide and > distinguish' *what*? I can't say I am clear on > that from either what you wrote (above), or what > John wrote (below). Sorry if it's obvious. Ron, When I wrote "divide and distinguish" I was speaking broadly ... in the sense of what I see the role a discriminator characteristic doing (which is to divide, distinguish, and unify, at some level of categorization scheme). For example, where 'actionable is currently placed, it (a) divides (partitions) 'directive', (b) distinguishes things of the two categories at that level, and (c) unifies (on that trait) since all things of a category at that level share that characteristic value. So when John wrote that our proposal was "extending the meaning of actionable" I took it to mean that, for him, it wasn't serving as discriminator in the taxonomy in those ways, where it is. Perhaps somewhere else in the taxonomy (which I assume since I didn't read "throw it out" into his alternative) -- just not where it is, in the role it's playing there. That's all I meant. And in the bits I quoted (still below) I saw suggestions of different ways to cut the pie (different needs to "divide and distinguish" [and unify]). I saw wording that talks about where "structural rules ... belong in" and being able to have models "not-too-tightly coupled" as implying a need to make different cuts of the overall pie. And, since it was presented under the banner of this issue, I read into that a proposal that "actionable" should play a role somewhere else in making those cuts. But I could be very well wrong in that interpretation. John would need to clarify that aspect. ~ Keri > In my mind, we have clearly and cleanly divided > and distinguished 'business policy' and 'elements > of guidance' for pragmatic purposes (which is > what counts). I can report from the field that > the distinctions work ... BRS has been applying > them for the best part of 10 years now to dozens > and dozens of clients in North America and > Europe, and business people and analysts > inevitably 'get it' and like it. And I've never > seen anyone confused by the "action" portion of > the "actionable" signifier, or somehow misapply it on the process side. > > However, if something needs clearing up, let's > get 'on it' ... "actionable" is a key concept of > both the business rule approach and of rules in SBVR. > > Ron > >> Certainly we need to be able to do that. But I feel that we >> *can* already do that, in rich and varied ways. I'd just not like to use >> *this* concept to (also) accomplish that goal. >> >> hope this helps, >> - Keri >> >> On 4/6/06 6:30 AM, "John Hall" wrote: >>> ... >>> So, even though you have stated it indirectly, I read your proposal as >>> extending the meaning of actionable to include ... >>> >>> The underlying issue is that structural business rules are part of >>> definitions. They belong in the concepts and vocabulary that provide a >>> common base for all the business models. ... >>> >>> 1) The other models need ... >>> >>> 2) It should be possible to integrate the 3 models fairly cleanly, because >>> a major objective is that they shouldn¹t interact very much. ... >>> Reply-To: From: "Conrad Bock" To: Subject: RE: OR-Join Definition, clarifications Date: Fri, 7 Apr 2006 12:22:57 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7ACwx/oYAAzqG0gBX3jcCA= -----Original Message----- From: Petko Chobantonov [mailto:Petko.Chobantonov@lombardisoftware.com] Sent: Friday, March 10, 2006 1:55 PM To: conrad.bock@nist.gov; BPMNFTF Subject: RE: OR-Join Definition, clarifications Conrad, > Activities (UML actions) that wait for incoming events are > considered to have tokens in them. This means an or-join downstream > of this activity can't be enabled if the activity is still waiting > for events. This is true even if no events ever come. Agree. But I don't see what the problem is? If they expect an event then the OR-Join should not be enabled before the event to arrive. I'm not very sure if you are talking about the following case: The message event is attached to the pool. In this case until the message is received there is no token on the message event e.g. the message event listens for an event and is activated only when the message event is received. Thus if the there is a token on the line "Task 1" to "J1" and there is no message received then J1 will be activated. If what they want to achieve is to wait for this message event then authors should use AND-Join. > Decision points upstream from the or-join may decide never to send > tokens along the path to the or-join. Since it is difficult to > analyze if this is the case, presumably the semantics will assume > that it might send token to or-join. So if tokens are upstream of > the decision point, the or-join cannot be enabled, even if the > decision point never sends tokens to the or-join. This is correct. And before executing this decision point the OR-Join will not be enabled. But after executing the decision gateway and deciding which paths should be taken then at that time the OR-Join will be enabled. > Activities that break down into further subactivities upstream > from the or-join are considered active as long as their > subactivities are executing (assuming BPMN doesn't support > asychronous invocation). Correct. And in this case any OR-Joins afterwards will not be enabled similar to how AND-Joins will not be enabled. In a virtual engine the analysis if an OR-Join is enabled should be performed every time an Flow Object is completed. This does not mean that an execution engine should try to check it every time e.g. the engine could be smarter to know if something was changed that could have invalidated previous analysis. Thus if something changes upstream the OR-Join will be checked again if it could be enabled. This does not mean that an OR-Join will be executed twice. An engine could check if a Flow Object is enabled multiple times, but it should execute it only once (assuming that an author did not specified otherwise) Petko -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Thursday, March 09, 2006 10:53 AM To: BPMNFTF Subject: RE: OR-Join Definition, clarifications Hi Petko, Just a reminder about these clarifications (added one more): image00173.jpg: 00000001,05b67fbc,00000000,60b461fb Reply-To: From: "Conrad Bock" To: Subject: RE: OR-Join Definition Date: Fri, 7 Apr 2006 12:23:32 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAAR6O8AABMgLQAAF1sfAAENZy4AFMLGEwAXK80UAA9F3fsAAlj6PQBIc7McA= -----Original Message----- From: Petko Chobantonov [mailto:Petko.Chobantonov@lombardisoftware.com] Sent: Wednesday, March 15, 2006 8:34 PM To: conrad.bock@nist.gov; bpmn-ftf@omg.org Subject: RE: OR-Join Definition Conrad, > - Upstream from the or-join along another flow line is an activity > that receives events from somewhere external to the process. As I understand this is the process that you are referring to: In this case we have a message event "Wait for message". There is a token on the sequence line between (Step 2, J1). There is also a token on "Wait for message". The fact that the real event could be received or not, does not matter for the OR-Join. In this case the execution engine knows that their is a token on this event. As a result a token could come. Thus the OR-Join will not be enabled. I'll discuss this example in detail. Here is the pseudo code of a Petri Net execution engine (I'm not claiming that this is the only option): a = findEnabledFlowObject(); while (thereAreTokensOnTheDiagram() && a != null) { // if a == null then we have to place the ProcessInstance in "suspended" state - // meaning it is possible the ProcessInstance to be resumed by receiving an event or when a task completes consumeTheTokensThatEnabled(a); // Here we are consuming (e.g. removing from the diagram) all tokens that enabled "a" placeTokenOn(a); execute(a); // execute could return a status "Suspend my execution until a specific notification on is received" if (a.completed()) { flowObjectCompleted_placeTokensOnTheDiagram(a); } a = findEnabledFlowObject(); } Here are the different states, that a flow object could go during execution: - Not enabled (On the diagram "Step 1" is in this state e.g. there are no tokens in any of the incoming lines) - Enabled (There is no flow object in this state on the diagram. If there was a token on the incoming line to "Step 3" then "Step 3" will be in "Enabled" state) - Active ("Wait for message") - Completed (This is a temporary state that a flow object will go through immediately after it is completed. It will trigger creation of tokens on any of the outgoing sequence flows - this depends on the split behavior of the flow object. For example: in the case of activity we have OR-Split behavior e.g. tokens will be placed on all lines for which the condition on every line evaluates to true) In this context all synchronization is done by checking if an flow object is enabled. Here is the check if AND-Join is enabled If there are tokens on all incoming sequence flows then the AND-Join is enabled. Here is the check if XOR-Join is enabled If there is 1 token on any incoming sequence flow then the XOR-Join (e.g. Data Gateway) is enabled. As you see the checks for AND-Join and OR-Joins are quite trivial. The check for OR-Join is // All must be true 1. There is at least 1 token on an incoming sequence flow 2. The number of consumed tokens cannot be increased by postponing the occurrence of the OR-Join considering the current Token Set. 3. During analysis if a specific OR-Join should be enabled, all other OR-Joins are treated as XOR-Gateways. This is an "Optimistic" Approach e.g. we are assuming that any OR-Join (different then the one we analyze) could be enabled as long as 1 token could arrive. I don't think we should make it more complicated then this. The deduction of (2) as an algorithm that is not trivial, but it is not too complicated. The goal is to make the life of a business analyst easier, not to make our work as developers of execution engines easier. Note: Again you can download an implementation of the algorithm from the sourceforge site. Here is the sequence of steps to check if "OR-Join" is enabled: (There are a lot of optimizations that I'm not showing here to make it simpler. ) 1. Is there a token on at least 1 incoming sequence flows? - "Yes". Then continue 2. Are there tokens on all sequence flows? "No" - This is just an optimization. If there are tokens on all incoming lines then obviously we cannot consume more => we can enable the OR-Join. This is not the case now. 3. CurrentSetOfTokens = { FlowObject("Wait for message"), SeqLine("Step2", "J1") } 4. We have to find all possible token sets that could be reached from the current token set. a. The token set that can be immediately reached from the current token set is: { SeqLine("Wait for message", "Step 4"), SeqLine("Step2", "J1") } b. The currently reviewed token sets are { { FlowObject("Wait for message"), SeqLine("Step2", "J1") }, { SeqLine("Wait for message", "Step 4"), SeqLine("Step2", "J1") } } c. From { FlowObject("Wait for message"), SeqLine("Step2", "J1") } we could reach to the new token set { FlowObject("Step 4"), SeqLine("Step2", "J1") } d. From { FlowObject("Step 4"), SeqLine("Step2", "J1") } we could reach to { SeqLine("Step 4", "J1"), SeqLine("Step2", "J1") }. If this state is reached then enabling J1 will consume 2 tokens. Thus we proved that it is possible more tokens to be consumed by delaying the execution of the OR-Join 5. Result: The OR-Join should not be enabled at this point I do agree that the proposed semantics is not local. I don't think that it is possible to achieve the same benefits using local semantics. And if someone knows a way then let's discuss it. To my knowledge in order to achieve somehow similar benefits, some engines use high level (colored) Petri Nets - meaning the tokens carry information that will be used during synchronization. For example using "False" / "True" tokens. This approach has a lot of issues - what to do when we decide to withdraw tokens from the graph? (and this is a common use case - For example: a problem was found and all tasks in some sub-process must be cancelled e.g. you cannot rely on the fact that some tokens will not be removed from the graph). Not to mention cycles here. I would like to mention that there is a difference between the Example 1 (above) and the following Example 2 In this case we have an attached event to the pool. The meaning is: If an event is received during the execution of this process then the event should be accepted and "Task 2" will be executed. The main difference between the 2 examples is: - Example 1: There is always a token on "Wait for message" - Example 2: A token will appear on the message only after the message is received. Those 2 examples illustrates 2 very important use cases: - Example 1: An author knows that a message event must come and the engine should wait for the message - Example 2: An author knows that a message event could arrive and if it arrives it should wait until a token comes from this path of the process. >> 3. During analysis if a specific OR-Join should be enabled, all other >> OR-Joins are treated as XOR-Gateways. This is an "Optimistic" >> Approach e.g. we are assuming that any OR-Join (different then the >> one we analyze) could be enabled as long as 1 token could arrive. > This means the actual execution could violate the second rule above, > because waiting could give more tokens to the "assumed XORs". Does > anyone in the group see business users thinking this way? If not, maybe > we should have semantic options for pessimism, moderate optimism (has > more than half the tokens), and other variations. :) The current approach does not have issues with cycles excluding the following: it is possible someone to build a process where in the same cycle > 2 OR-Joins are used that satisfy this condition: R1: An OR-Join "A" is on directed path to OR-Join "B" and "B" is on directed path to "A". In this case the behavior previously was not guaranteed e.g. it was possible 2 different vendors to provide 2 different results depending on how they will evaluate all other OR-Joins different then the OR-Join in question. To guarantee the semantics I've added the 3-rd rule. The treatment of all other OR-Joins as XOR-Joins during analysis guarantees that the behavior in this case is defined as "it will result in deadlock". This is discussed in section 4.5 of the document. It is easy to build an analysis engine to detect this case and to warn a business analyst that this could result in deadlock. It is similar to the following AND-Join use case: This process will always result in deadlock: It is not possible the AND-Join to be activated. Also you can also define a Pessimistic approach. But this is not what a normal business analyst will expect. In this case you can treat all other OR-Joins (excluding the one that you perform the analysis on) as AND-Joins. Here you can find more information (have a look at section 2.3): http://www.yawl.fit.qut.edu.au/yawldocs/ORJoin_PN05.pdf Section Petko image00174.jpg: 00000001,2a9c06c8,00000000,60b461fb image003.jpg: 00000001,3b5d6db4,00000000,60b46247 >>> In other words, we should have (at least) three not-too-tightly coupled X-ASG-Debug-ID: 1146764715-4878-97-3 X-Barracuda-URL: http://10.3.1.19:8000/cgi-bin/mark.cgi X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 04 May 2006 12:44:24 -0500 To: SBVR-FTF From: "Ronald G. Ross" X-ASG-Orig-Subj: Re: Issue 9447 -- SBVR FTF issue [resolution] Subject: Re: Issue 9447 -- SBVR FTF issue [resolution] X-Virus-Scanned: by Barracuda Spam Firewall at stayonline.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=4.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.12031 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- All, Attached is the resolution write-up for Issue 9447 as agreed and promised at the last SBVR FTF meeting. Ron Issue9447.doc Disposition: Resolved OMG Issue No: 9447 Title: .Fact Model. vs. .Conceptual Model. Source: Business Rule Solutions, LLC, Ronald G. Ross (rross@BRSolutions.com) Summary: The relation of the terms .fact model. (as used in 10.1.1) and .conceptual model. (as used in all other sections) was not clarified and properly entered into the SBVR vocabulary. Resolution: 1. Add .fact model. to Meaning and Representation Vocabulary (for the meaning now given to .conceptual model.). 2. Make .fact model. the preferred term, making .conceptual model. a synonym. 3. .A fact model is specified as a conceptual model .. on page 73 (10.1.1.2) must be changed to .A fact model is a conceptual model ... Revised Text: Note: In making the changes that follow, all singular/plural forms, and all fonts, are to be preserved as they currently appear in the document. Instruction 1. pp. 31--32 ... in the Definition for "fact type is internally closed in conceptual schema" ... Change "conceptual model" to "fact model" in each of the 3 instances below. Definition: in each conceptual model based on the conceptual schema, for each instance of the fact type, the conceptual model includes a corresponding fact if, for each thing filling any of the fact types roles in the instance, the conceptual model also includes a fact of the existence of that thing Instruction 2. In the diagram at the top of p. 31 ... Change "conceptual model" to "fact model" in each of the 2 instances below. a.) In the box that is currently labeled "conceptual model". b.) In the fact type (at the bottom of the diagram) that currently reads: "[fact type] has [fact] in [conceptual model]". Instruction 3. pp. 32 ... In the Note at the top of the page ... Change "conceptual model" to "fact model" in the 1 appearance below. Open world semantics are assumed by default, but closure may be explicitly asserted for any fact type, on an individual basis, to declare that each conceptual model population agrees with that of the fact types extension in the actual business domain. Semi-closure is with respect to the domain model population of the noun concepts playing a role in the fact type. In other words, if the things participating in a fact are known within a model, then the fact is also known within that model. Instruction 4. p. 32 ... In the Definition for "concept is closed in conceptual schema" ... Change "conceptual model" to "fact model" in each of the 2 instances below. Definition: in each conceptual model based on the conceptual schema, the entire extension of the concept is given in the facts included in the conceptual model Instruction 5. p. 32 ... Change the entry currently called "conceptual model" to "fact model". Instruction 6. p. 32 ... After the Definition for the entry currently called "conceptual model" (now to be called "fact model"), add the following captioned line: Synonym conceptual model Instruction 7. pp. 32 ... In the Note after the Definition for conceptual model (now "fact model") ... Change "conceptual model" to "fact model" in the 1 appearance below. Each necessity of the conceptual schema is satisfied by a conceptual model, but obligations are not necessarily satisfied. Instruction 8. p. 32 ... Change the entry currently called "conceptual model is based on conceptual schema" to "fact model is based on conceptual schema". Instruction 9. p. 32 ... In the Definition for "conceptual model is based on conceptual schema" (now to be called "fact model is based on conceptual schema"), change "conceptual model" to "fact model" in the 1 appearance below. the conceptual schema provides the concepts and modal facts of the conceptual model Instruction 10. pp. 32 ... In the Synonymous Form given after the Definition for "conceptual model is based on conceptual schema" (now to be called "fact model is based on conceptual schema"), change "conceptual model" to "fact model" in the 1 appearance below. Synonymous Form: conceptual schema underlies conceptual model Instruction 11. p. 32 ... Change the entry currently called "conceptual model includes fact" to "fact model includes fact". Instruction 12. p. 32 ... In the Definition for "conceptual model includes fact" (now to be called "fact model includes fact"), change "conceptual model" to "fact model" in the 1 appearance below. Definition: the fact corresponds to an actuality in the possible world modeled by the conceptual model Instruction 13. pp. 32 ... In the Synonymous Form given after the Definition for "conceptual model includes fact" (now to be called "fact model includes fact"), change "conceptual model" to "fact model" in the 1 appearance below Synonymous Form: fact is in conceptual model Instruction 14. p. 32 ... Change the entry currently called "fact type has fact in conceptual model" to "fact type has fact in fact model". Instruction 15. p. 32 ... In the Definition for "fact type has fact in conceptual model" (now to be called "fact type has fact in fact model"), change "conceptual model" to "fact model" in the 1 appearance below. the fact is in the conceptual model and the fact corresponds to an instance of the fact type Instruction 16. p. 34 In the introductory text for 8.6.2 Necessities Governing Extension, change "conceptual model" to "fact model" in the 1 appearance below. The following statements of necessity apply to the relationships between a meaning and its extension. Other necessities stated in the context of the Meaning and Representation Vocabulary concern the contents of conceptual schemas and their representations. But the following necessities concern each conceptual model in relation to the conceptual schema that underlies it. Instruction 17. p. 71 In the 2nd paragraph, change "conceptual model" to "fact model" in the 7 appearances below. A conceptual model includes both a conceptual schema and a population of facts that conform to the schema. A conceptual model may cover any desired time span, and contain facts concerning the past, present or future. This notion is distinct from changes made to a conceptual model. Any change to a conceptual model, including any change to any fact in the fact population, creates a different conceptual model. Each conceptual model is distinct and independent, although there may be relationships between conceptual models that share the same conceptual schema. Instruction 18. p. 71 In the 4th paragraph, change "conceptual model" to "fact model" in the 2 appearances below. SBVR makes no distinction about how facts are known: for example, whether they are asserted as 'ground facts' or obtained by inference. Inferences can only be performed at one time within a particular conceptual model. SBVR does not define any kind of inference that can be made between conceptual models. Instruction 19. p. 71 In the 5th paragraph, change "conceptual model" to "fact model" in the 1 appearance below. Control over the order in which inferences can be made is a common feature in the automation of inference, as found, for example, in rules engines. SBVR deals with declarative rules expressed from a business perspective. Transitions between conceptual models and the mechanization of those rules in an automated system are outside the scope of SBVR. Instruction 20. p. 73 In the next to last paragraph, first sentence (replicated below), change A fact model is specified as a conceptual model to A fact model is a conceptual model . A fact model is specified as a conceptual model of the business domain, using a suitable high level vocabulary and language that is readily understood by the business domain experts. Instruction 21. p. 102 ... 10.3.2.1 Mapping to Formal Logic, change " "conceptual model" to "fact model" in the 6th row of the table. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Disposition: Resolved User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 09 May 2006 07:16:51 -0700 Subject: Re. Issue 9477 -- proposed resolution From: John and Keri To: SBVR-FTF Thread-Topic: Re. Issue 9477 -- proposed resolution Thread-Index: AcZzczchdcJOwN9mEdqWkwARJM+Cgg== All, I was asked to prepare a document that would show the results of applying the proposed changes. See attached. ~ Keri Issue9477-applied.doc On PDF page 138 directive is actionable Concept Type: characteristic Note:.Actionable. means that a person who knows about the directive could observe a relevant situation (including his or her own behavior) and decide directly whether or not the business was complying with the directive. Definition: the directive is sufficiently detailed and precise that a person who knows the directive can apply it effectively and consistently in relevant circumstances to know what behavior is acceptable or not, or how something is decided or calculated Dictionary Basis:subject to or affording ground for an action or suit at law [MWUD .actionable.] Dictionary Basis:a thing done : DEED [MWUD (5a) .action.] Note: The sense intended is: .It.s actually something you can put to use or apply.. Note: The behavior, decision, or calculation can be that person.s own. Note: Whether or not some element of guidance is actionable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. o For a structural business rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. Note: An actionable business rule is also always free of any indefinite reference to people (e.g., .you., .me.), places (e.g., .here.), and time (e.g., .now.). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to .tell. time), and (b) external clarification. On PDF page 178 A.2.3.3 Additional Comments about Business Rules What 'Actionable' Means All business rules need to be actionable. This means that a person who knows about a business rule could observe a relevant situation (including his or her own behavior) and decide directly whether or not the business was complying with the rule. This assumes, of course, that the business vocabulary on which the rule is based has been adequately developed, and has been made available in some appropriate manner. This points toward the essential role of business vocabulary in supporting business rules; indeed, the bulk of SBVR is devoted to that area. All business rules (and affirmations and admonitions as well) need to be actionable. Whether or not some element of guidance is actionable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. If an operative business rule is actionable, a person who knows about it can decide directly whether it is being followed when that person observes relevant behavior. o For a structural business rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. If a structural business rule is actionable, a person who knows about it can also decide directly whether it is being followed when that person observes some relevant outcome from a decision or calculation. An actionable business rule is also always free of any indefinite reference to people (e.g., .you., .me.), places (e.g., .here.), and time (e.g., .now.). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to .tell. time), and (b) external clarification. All these criteria assume that the person understands the business concepts that underlie the business rule. An actionable business rule always imparts ready-to-apply knowledge of the kinds above .on top. of such concepts. An important best practice for business rules, following naturally from this, is that the underlying business vocabulary/ies must be well developed and well managed. Specifically, each business concept should: o Be individually well defined. o Fit logically into the overall structure of concepts. o Made available to the person in appropriate manner. In addition, each business rule should be directly expressible in the given business vocabulary/ies. These best practices point toward the essential role of business vocabularies in supporting business rules . indeed, the bulk of SBVR is devoted to that area. A.2.3.4 Business Rules that Cannot Be Automated Just because business rules are actionable, this does not imply they are always automatable. Many business rules, especially operative business rules, are not automatable in IT systems. For instance, consider the obligation example given above. This distinction is not important within SBVR, which focuses on rules only from the business perspective, regardless of whether the rules could be automated. However, it is obviously important in defining a transformation from business model to PIM. In particular, non-automatable business rules need to be implemented as user activity, supported by procedure manuals or rulebooks. User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 09 May 2006 07:21:03 -0700 Subject: Re: Re. Issue 9477 -- proposed resolution From: John and Keri To: SBVR-FTF Thread-Topic: Re. Issue 9477 -- proposed resolution Thread-Index: AcZzczchdcJOwN9mEdqWkwARJM+CggAAJY2e Please reply if you spot anything that I got wrong, or that does not correctly reflect the nature/scope of the proposed resolution to this Issue. thanks, ~ Keri On 5/9/06 7:16 AM, "John and Keri" wrote: > All, > > I was asked to prepare a document that would show the results of applying > the proposed changes. See attached. > > ~ Keri > X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 09 May 2006 09:31:15 -0500 To: John and Keri , SBVR-FTF From: "Ronald G. Ross" Subject: Re: Re. Issue 9477 -- proposed resolution At 09:21 AM 5/9/2006, John and Keri wrote: Please reply if you spot anything that I got wrong, or that does not correctly reflect the nature/scope of the proposed resolution to this Issue. I looked it over quickly and did not spot any problems. Ron thanks, ~ Keri On 5/9/06 7:16 AM, "John and Keri" wrote: > All, > > I was asked to prepare a document that would show the results of applying > the proposed changes. See attached. > > ~ Keri > User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 10 May 2006 12:48:01 -0700 Subject: Re: Issue 9477 -- proposed resolution From: John and Keri To: SBVR-FTF Thread-Topic: Issue 9477 -- proposed resolution Thread-Index: AcZzczchdcJOwN9mEdqWkwARJM+CggA923ad On 4/25/06 12:05 PM, "John and Keri" wrote: > Attached is the updated proposed resolution document for Issue 9477, replacing > the previously-submitted file (named "Actionable v5.doc"). > > Note that this is now part of a joint proposed resolution, i.e., part of the > proposed resolution of Issue 9579. > > regards, > Keri > file: Actionable v6.doc Per last week's meeting 'action item' here is my input on this Issue: * I do not characterize this Issue as being about the definition of 'actionable'. As one of the original authors of the Issue (and of the proposal that is on the table), my perspective is that this Issue is about correcting/improving the meaning of the concept that is used to distinguish kinds of 'directive' -- i.e., business policy from element of guidance. The resolution on the table provides that improved wording of the concept's meaning and provides additional, explanatory notes. * The term 'actionable' that is used in the form of expression serving as the primary representation for that now-improved meaning has, off and on, had discussion about perhaps finding a better signifier. We have entertained discussion on that notion (which was not, by the way, part of the Issue we submitted). At this time, no better signifier has emerged. Accordingly, I request that we not hold up this Issue's resolution while that search for some "better term" continues. * If someone has other issues relating to 'actionable', or wants other characteristics that make other distinctions in other parts of the rule taxonomy, I urge that they be submitted as new, specific Issues (rather than pilling on to this Issue with points never intended). regards, Subject: RE: SBVR-FTF Issue 9477 - re: "Actionable" Date: Thu, 11 May 2006 11:13:31 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SBVR-FTF Issue 9477 - re: "Actionable" Thread-Index: AcZotFcFlV67mNSnEdqMXwARJM+CggMbFxzA From: "Baisley, Donald E" To: "SBVR-FTF" X-OriginalArrivalTime: 11 May 2006 18:13:32.0447 (UTC) FILETIME=[9CADA2F0:01C67526] There seems to be desires for two notions of .actionable.. Problems seem to come from confusion resulting from differences in the generalization hierarchy of guidance given in SBVR from the way we normally use words. How would you respond to the following questions? Please answer. I have given my answers, but please state what you think. Do we agree that a structural rule is an element of guidance? I do. It seems to me that .guidance. is a fairly general concept. Do we agree that a structural rule is a rule? I do. Is a directive an element of guidance? I would say yes based on normal dictionary definitions. Is a business policy an element of guidance? I would say yes based on normal dictionary definitions. Do we agree that every structural rule is a directive? I don.t, at least not by my understanding of the common meaning of .directive.. I think .directive. should specialize .element of guidance.. Specializations of .directive. should include .business policy. (as it does now) and .operative business rule., and should exclude .structural rule.. But that.s because I think of .directive. as being about what people must do, not about what is necessarily true. Are structural rules always actionable*? [* - as defined in the currently proposed .is actionable. definition] Ron says he commonly sees structural rules that are too fuzzy to be actionable*. If it is possible for a structural rule to not be actionable*, then SBVR.s current generalization hierarchy is messed up. Is business policy always necessarily excluded from a community.s body of shared guidance? I don.t think so. I think policy can and should be part of a community.s body of shared guidance. Policy can be clear and understood, even though it is not actionable. I would like to see your answers? Regards, Don X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 11 May 2006 13:29:04 -0500 To: "Baisley, Donald E" , "SBVR-FTF" From: "Ronald G. Ross" Subject: RE: SBVR-FTF Issue 9477 - re: "Actionable" At 01:13 PM 5/11/2006, Baisley, Donald E wrote: Are structural rules always actionable*? [* - as defined in the currently proposed .is actionable. definition] Ron says he commonly sees structural rules that are too fuzzy to be actionable*. If it is possible for a structural rule to not be actionable*, then SBVR.s current generalization hierarchy is messed up. Here's the right way to say what I meant. "I often see statements that are too fuzzy to be actionable, which if clarified, would probably be structural rules." Sorry if my shorthand confused anyone. Obviously a "rule" that is not actionable [i.e., fuzzy] is *not* a rule. Ron Regards, Don Reply-To: From: "Donald Chapin" To: "'SBVR-FTF'" Subject: RE: Re. Issue 9477 -- proposed resolution Date: Wed, 17 May 2006 20:11:57 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZzczchdcJOwN9mEdqWkwARJM+CggGYggHw All -- There are two fundamental problems with this proposed Issue resolution that need to be addressed before we get into details. FUNDAMENTAL PROBLEM 1 The Note: ('Actionable' means...) should not be deleted because there are two different concepts: - the concept defined by the Note: 'Actionable' means .....) - a new concept being proposed in this proposed resolution The pragmatic categorization that is focused around "most of the people in a community being able to come to the same conclusion about whether or not a particular situation is compliant with a given directive because that directive enables such a consistent determination" is very valuable. While the Note may not gather up the whole meaning of this concept as well as it should, we must not lose this meaning/concept by changing its definiton. I suggest that we agree that there are two separate concepts and that someone raises a separate Issue to create a proper definition that the original concept that has Note: ('Actionable' means....). FUNDAMENTAL PROBLEM 2 Strucutral rules are 'true by definition'. A synonym for 'strucutral rule' is 'definitonal rule'. Each structural rule is one representation of a delimiting component of the intension of one concept, which may be a verb concept, even a non-elementary verb concept. Representations of intensions of concepts are either correct or incorrect (depending on how accurately they represent the images/meanings/concpets in the minds of, and shared by, the members of the semantic community). Classifying them by degree of detail or degree of precision is meaningless. The concept means what the representation of its intension says it means. It's a different concept if the represenation of its intension is more or less precise or more or less detailed. I suppose some categorization of the fitness for purpose of a concept might be useful, but that is not what the proposed resolution is proposing. Once we resolve these two fundamental problems with the proposed resolution, then it would be appropriate to discuss its details Donald > -----Original Message----- > From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] > Sent: 09 May 2006 15:17 > To: SBVR-FTF > Subject: Re. Issue 9477 -- proposed resolution > > All, > > I was asked to prepare a document that would show the results of applying > the proposed changes. See attached. > > ~ Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 17 May 2006 12:27:59 -0700 Subject: Re: Re. Issue 9477 -- proposed resolution From: John and Keri To: SBVR-FTF Thread-Topic: Re. Issue 9477 -- proposed resolution Thread-Index: AcZzczchdcJOwN9mEdqWkwARJM+CggGYggHwAASwksA= Donald, As one of the authors of this issue, I would rather withdraw the Issue than get into what you suggest below. This was intended to be a simple improvement in wording, but if you won't take it that way, I would say that the notion should stay just as it is. - Keri On 5/17/06 12:11 PM, "Donald Chapin" wrote: > All -- > > There are two fundamental problems with this proposed Issue resolution that > need to be addressed before we get into details. > > FUNDAMENTAL PROBLEM 1 > > The Note: ('Actionable' means...) should not be deleted because there are > two different concepts: > > - the concept defined by the Note: 'Actionable' means .....) > - a new concept being proposed in this proposed resolution > > The pragmatic categorization that is focused around "most of the people in a > community being able to come to the same conclusion about whether or not a > particular situation is compliant with a given directive because that > directive enables such a consistent determination" is very valuable. > > While the Note may not gather up the whole meaning of this concept as well > as it should, we must not lose this meaning/concept by changing its > definiton. > > I suggest that we agree that there are two separate concepts and that > someone raises a separate Issue to create a proper definition that the > original concept that has Note: ('Actionable' means....). > > > FUNDAMENTAL PROBLEM 2 > > Strucutral rules are 'true by definition'. A synonym for 'strucutral rule' > is 'definitonal rule'. > > Each structural rule is one representation of a delimiting component of the > intension of one concept, which may be a verb concept, even a non-elementary > verb concept. > > Representations of intensions of concepts are either correct or incorrect > (depending on how accurately they represent the images/meanings/concpets in > the minds of, and shared by, the members of the semantic community). > > Classifying them by degree of detail or degree of precision is meaningless. > The concept means what the representation of its intension says it means. > It's a different concept if the represenation of its intension is more or > less precise or more or less detailed. > > I suppose some categorization of the fitness for purpose of a concept might > be useful, but that is not what the proposed resolution is proposing. > > > Once we resolve these two fundamental problems with the proposed resolution, > then it would be appropriate to discuss its details > > Donald > > > >> -----Original Message----- >> From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] >> Sent: 09 May 2006 15:17 >> To: SBVR-FTF >> Subject: Re. Issue 9477 -- proposed resolution >> >> All, >> >> I was asked to prepare a document that would show the results of applying >> the proposed changes. See attached. >> >> ~ Keri > > > X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 17 May 2006 14:30:39 -0500 To: , "'SBVR-FTF'" From: "Ronald G. Ross" Subject: RE: Re. Issue 9477 -- proposed resolution At 02:11 PM 5/17/2006, Donald Chapin wrote: All -- There are two fundamental problems with this proposed Issue resolution that need to be addressed before we get into details. FUNDAMENTAL PROBLEM 1 The Note: ('Actionable' means...) should not be deleted because there are two different concepts: - the concept defined by the Note: 'Actionable' means .....) - a new concept being proposed in this proposed resolution The pragmatic categorization that is focused around "most of the people in a community being able to come to the same conclusion about whether or not a particular situation is compliant with a given directive because that directive enables such a consistent determination" is very valuable. While the Note may not gather up the whole meaning of this concept as well as it should, we must not lose this meaning/concept by changing its definiton. I suggest that we agree that there are two separate concepts and that someone raises a separate Issue to create a proper definition that the original concept that has Note: ('Actionable' means....). Your message is very vague. If you think there are two concepts, you should suggest what they are (explicitly). Obviously (speaking only for myself), if I had thought there were two concepts, I would have written that out in the first place. Please xplain? FUNDAMENTAL PROBLEM 2 Strucutral rules are 'true by definition'. A synonym for 'strucutral rule' is 'definitonal rule'. Each structural rule is one representation of a delimiting component of the intension of one concept, which may be a verb concept, even a non-elementary verb concept. Please explain your use of "delimiting". Are you saying that *every* structural rule that pertains to a concept is 'delimiting'? Even ISO talks about 'non-essential' characteristics (I believe they are called). And where does "necessary and sufficient" fit? Thanks, Ron Representations of intensions of concepts are either correct or incorrect (depending on how accurately they represent the images/meanings/concpets in the minds of, and shared by, the members of the semantic community). Classifying them by degree of detail or degree of precision is meaningless. The concept means what the representation of its intension says it means. It's a different concept if the represenation of its intension is more or less precise or more or less detailed. I suppose some categorization of the fitness for purpose of a concept might be useful, but that is not what the proposed resolution is proposing. Once we resolve these two fundamental problems with the proposed resolution, then it would be appropriate to discuss its details Donald > -----Original Message----- > From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] > Sent: 09 May 2006 15:17 > To: SBVR-FTF > Subject: Re. Issue 9477 -- proposed resolution > > All, > > I was asked to prepare a document that would show the results of applying > the proposed changes. See attached. > > ~ Keri Subject: RE: issue 9477 -- SBVR FTF issue Date: Tue, 1 Aug 2006 17:14:43 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: issue 9477 -- SBVR FTF issue thread-index: AcZSsH8Y361z8s2aQZCl3601Gbjn6hjFyUWA From: "Baisley, Donald E" To: X-OriginalArrivalTime: 02 Aug 2006 00:14:44.0381 (UTC) FILETIME=[A807D4D0:01C6B5C8] Issue9477.doc has the proposed resolution of 9477 that was discussed in London. Keri provided the updated figure within the document. When she did so, she also did us a great favor by providing Issue9477-applied.doc showing how the changed portions of the document look with the changes applied. Thank you Keri. Regards, Don PS . Keri, do we need to also submit the figure as a separate eps file? Issue9477.doc Issue9477-applied.doc Disposition: Resolved OMG Issue No: 9477 Title: Actionable Source: Ron Ross Summary: The current notion of "actionable" falls short in several regards: * It does not take into account structural (definitional) rules. * Its wording is based on "complying", which is only appropriate for operative (behavioral) rules. * It fails to address the issue of lexical indexicals -- conversational references to person, place and time. Resolution: Make separate fact types for .is practicable. and .is actionable.. Rearrange the generalization hierarchy in 12.1 to better represent commonly understood usage of terms. Add further explanation to Annex A. Revised Text: Replace Figure 12.1 on page 137 with the following: In 12.1.1 on page 138 make the following changes to the entry for .element of guidance.. 1. Replace the Definition with the following: Definition: means that guides, defines or constrains some aspect of an enterprise 2. Add the following Note: Note: This sense of .means. (as in .ends and means., rather than .is meant as.) arises from the Business Motivation Model [BMM]. 3. Delete the Necessity. 4. Move the entire entry for .element of guidance. to be at the front of section 12.1.1, in front of the entry for .directive.. 5. Put the following Note (previously given for .directive.) at the end of the entry for .element of guidance.: Note: The formulation of an element of guidance is under an enterprise.s control by a party authorized to manage, control or regulate the enterprise, by selection from alternatives in response to a combination of assessments. In 12.1.1 on page 138 after the entry for .element of guidance. add the following new entry: element of guidance is practicable Concept Type: characteristic Definition: the element of guidance is sufficiently detailed and precise that a person who knows the element of guidance can apply it effectively and consistently in relevant circumstances to know what behavior is acceptable or not, or how something is decided or calculated Dictionary Basis: able to be done or put into practice successfully; able to be used, useful [ODE] Note: The sense intended is: .It.s actually something you can put to use or apply.. Note: The behavior, decision, or calculation can be that person.s own. Note: Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. Note: A practicable business rule is also always free of any indefinite reference to people (e.g., .you., .me.), places (e.g., .here.), and time (e.g., .now.). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to .tell. time), and (b) external clarification. In 12.1.1 on page 138 replace the entire entry for .directive. by the following: directive Definition: official or authoritative instruction involving the management or guidance of operations General Concept: element of guidance Dictionary Basis: an official or authoritative instruction [NODE] In 12.1.1 on page 138 under the entry .directive is actionable. make the following changes: 1. Add the following definition at the front. Definition: the directive is able to be done or acted upon; is practicable 2. Remove the two .Dictionary Basis:. lines. 3. Drop the Note at the end: The sense intended is: .It.s actually something you can put to use or apply.. 4. Add the following two Necessities at the end: Necessity: Each directive that is actionable is practicable. Necessity: A directive that is not actionable is not practicable. In 12.1.1 on page 138 in make the following changes to the entry .element of guidance is based on fact type.. 1. Replace the term .element of guidance. with .proposition. in the form of expression so that it becomes .proposition is based on fact type.. 2. In the Definition, replace .element of guidance. with .proposition.. 3. In the Example, replace .element of guidance (business rule). with .business rule.. In 12.1.1 on page 138 at the end of the entry for .business policy. add the following Necessity and Example. Necessity: No business policy is an operative business rule. Example: The policy expressed as "A prisoner is considered to be on a hunger strike after missing several meals in a row." In 12.1.2 on page 139 in the entry for .rule. replace the definition and add the following General Concept line after the definition. Definition: element of guidance that is practicable and that is a proposition that introduces an obligation or a necessity General Concept: element of guidance, proposition In 12.1.2 on page 139 in the entry for .operative business rule. add the following General Concept line after the last definition. General Concept: business rule, directive In 12.1.4 on page 140 in the entry for .admonition. replace the definition and add the following General Concept line after the definition. Definition: element of guidance that is practicable and that is a proposition that there is not an obligation or necessity where, by custom or practice, one might be assumed General Concept: element of guidance, proposition In 12.1.4 on page 141 in the entry for .affirmation. replace the definition and add the following General Concept line after the definition. Definition: element of guidance that is practicable and that is a proposition that there is a permissibility or possibility where, by custom or practice, one might not be assumed General Concept: element of guidance, proposition Replace section A.2.3.3 with the following two sections. Note that the second section is a slightly modified version of the last two paragraphs of the original A.2.3.3. A.2.3.3 What 'Practicable' Means All business rules (and affirmations and admonitions as well) need to be practicable. Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. If an operative business rule is practicable, a person who knows about it can decide directly whether it is being followed when that person observes relevant behavior. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. If a structural rule is practicable, a person who knows about it can also decide directly whether it is being followed when that person observes some relevant outcome from a decision or calculation. A practicable business rule is also always free of any indefinite reference to people (e.g., .you., .me.), places (e.g., .here.), and time (e.g., .now.). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to .tell. time), and (b) external clarification. All these criteria assume that the person understands the business concepts that underlie the business rule. A practicable business rule always imparts ready-to-apply knowledge of the kinds above .on top. of such concepts. An important best practice for business rules, following naturally from this, is that the underlying business vocabulary/ies must be well developed and well managed. Specifically, each business concept should: o Be individually well defined. o Fit logically into the overall structure of concepts. o Made available to the person in appropriate manner. In addition, each business rule should be directly expressible in the given business vocabulary/ies. These best practices point toward the essential role of business vocabularies in supporting business rules . indeed, the bulk of SBVR is devoted to that area. A.2.3.4 Business Rules that Cannot Be Automated Just because business rules are practicable, this does not imply they are always automatable. Many business rules, especially operative business rules, are not automatable in IT systems. For instance, consider the obligation example given above. This distinction is not important within SBVR, which focuses on rules only from the business perspective, regardless of whether the rules could be automated. However, it is obviously important in defining a transformation from business model to PIM. In particular, non-automatable business rules need to be implemented as user activity, supported by procedure manuals or rulebooks. Disposition: Resolved 12 Business Rules _____________________________________________________ Vocabulary for Describing Business Rules Language: English Included Vocabulary: Vocabulary for Describing Business Vocabulary _____________________________________________________ 12.1 Categories of Guidance Figure 12.1 ___________________________________________________________________ This diagram is not normative abstract syntax for SBVR, but is for illustration only. ___________________________________________________________________ 12.1.1 Guidance element of guidance Definition: means that guides, defines or constrains some aspect of an enterprise Note: This sense of 'means' (as in 'ends and means', rather than 'is meant as') arises from the Business Motivation Model [BMM]. Note: The formulation of an element of guidance is under an enterprise.s control by a party authorized to manage, control or regulate the enterprise, by selection from alternatives in response to a combination of assessments. element of guidance is practicable Concept Type: characteristic Definition: the element of guidance is sufficiently detailed and precise that a person who knows the element of guidance can apply it effectively and consistently in relevant circumstances to know what behavior is acceptable or not, or how something is decided or calculated Note: The sense intended is: "It's actually something you can put to use or apply." Note: The behavior, decision or calculation can be that person's own. Note: Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. Note: A practicable business rule is also always free of any indefinite reference to people (e.g., "you", "me"), places (e.g., "here"), and time (e.g., "now"). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to "tell" time), and (b) external clarification. directive Definition: official or authoritative instruction involving the management or guidance of operations General Concept: element of guidance Dictionary Basis: an official or authoritative instruction [NODE] directive is actionable Definition: the directive is able to be done or acted upon; is practicable Concept Type: characteristic Note: 'Actionable' means that a person who knows about the directive could observe a relevant situation (including his or her own behavior) and decide directly whether or not the business was complying with the directive. Necessity: Each directive that is actionable is practicable. Necessity: A directive that is not actionable is not practicable. business policy Definition: directive that is not actionable whose purpose is to guide an enterprise Note: Compared to a Business Rule, a Business Policy tends to be: - less structured - less discrete or not atomic - less carefully expressed in terms of standard vocabulary - not directly actionable. Dictionary Basis: definite course or method of action selected (as by a government, institution, group, or individual) from among alternatives and in the light of given conditions to guide and usually determine present and future decisions [MWUD "Policy" 5a] Necessity: No business policy is an operative business rule. Example: The policy expressed as "A prisoner is considered to be on a hunger strike after missing several meals in a row." proposition is based on fact type Definition: the proposition is formulated using the fact type Example: The EU-Rent business rule that is expressed as "It is obligatory that each rental specifies a car group." (or, in RuleSpeak, "A rental must have a car group.") is based on the EU-Rent fact type 'rental specifies car group'. body of shared guidance Definition: all of the elements of guidance within a body of shared meanings On PDF page 139 body of shared meanings includes body of shared guidance body of shared guidance includes element of guidance 12.1.2 Rules rule Definition: element of guidance that is practicable and that is a proposition that introduces an obligation or a necessity General Concept: element of guidance, proposition Dictionary Basis: one of a set of explicit or understood regulations or principles governing conduct or procedure within a particular area of activity. a law or principle that operates within a particular sphere of knowledge, describing or prescribing what is possible or allowable. [ODE] [per proposed resolution to Issue 9579] business rule Definition: rule that is under business jurisdiction business rule is derived from business policy Synonymous Form: business policy is basis for business rule structural rule Definition: rule that is intended as a definitional criterion Necessity: Each structural rule is a proposition that another proposition is a necessity. Synonym: definitional rule definitional rule See: structural rule structural business rule Definition: structural rule that is a business rule Synonym: definitional business rule definitional business rule See: structural business rule operative business rule Definition: business rule that is intended to produce an appropriate or designed effect Definition: business rule that covers conduct, action, practice, or procedure within a particular activity or sphere Definition: business rule that there is an obligation concerning conduct, action, practice or procedure General Concept: business rule, directive Dictionary Basis: a prescribed, suggested, or self-imposed guide for conduct or action : a regulation or principle [.] [MWU (1a) 'rule'] Dictionary Basis: a prescribed guide for conduct or action [MWCD 'rule'] Necessity: Each operative business rule is a proposition that another proposition is an obligation. Necessity: No operative business rule is a structural business rule. Synonym: behavioral business rule behavioral business rule See: operative business rule 12.1.3 Enforcement level of enforcement Definition: something that represents a position in a graded or ordered scale of values that specifies the severity of action imposed in order to put or keep an operative business rule in force Dictionary Basis: a position on a real or imaginary scale of amount, quantity, extent, or quality [NODE 'level'] On PDF page 140 Dictionary Basis: compel observance of or compliance with [NODE 'enforcement'] Example: An example set of levels of enforcement, based on [BRG-ODP] Enforcement Level: strict Description: strictly enforced (If you violate the rule, you cannot escape the penalty.) Enforcement Level: deferred Description: deferred enforcement (Strictly enforced, but enforcement may be delayed . e.g., waiting for resource with required skills.) Enforcement Level: pre-authorized Description: pre-authorized override (Enforced, but exceptions allowed, with prior approval for actors with before-the-fact override authorization.) Enforcement Level: post-justified Description: post-justified override (If not approved after the fact, you may be subject to sanction or other consequences.) Enforcement Level: override Description: override with explanation (Comment must be provided when the violation occurs.) Enforcement Level: guideline Description: guideline (suggested, but not enforced.) operative business rule has level of enforcement 12.1.4 Admonitions and Affirmations admonition Definition: element of guidance that is practicable and that is a proposition that there is not an obligation or necessity where, by custom or practice, one might be assumed General Concept: element of guidance, proposition Note: The purpose of an admonition is to preempt application of "rules" that might be assumed by some members of a semantic community, but are not actually rules admitted by the community. Often, the reason for this assumption in a business is that other, similar, businesses have such rules. Typically, the reason for an explicit admonition is that people in the business have mistakenly applied the non-existent "rule" in the past. Example: (In a bank) There is no rule that a person must be over some given age in order open a savings account: "There is no minimum age for opening a savings account". Example: (In EU-Rent) There is no rule that a rented car can be dropped off only at the return branch specified in the rental agreement: "At the end of a rental, a rental car can be dropped off at any EU-Rent branch". There is a related rule that if the drop-off branch is not the specified return branch, the rental will incur a penalty charge, but the importance of this admonition is that EU-Rent wants its cars back, even if they are in the wrong places. It does not want a branch to refuse to accept a car on the grounds that it is not the specified return branch. On PDF page 141 Necessity: Each admonition is a proposition that another proposition is not an obligation or a necessity. Necessity: No rule is an admonition. affirmation Definition: element of guidance that is practicable and that is a proposition that there is a permissibility or possibility where, by custom or practice, one might not be assumed General Concept: element of guidance, proposition Example: (In a bank) "It is possible that an account balance is negative". Example: (In EU-Rent) "A rental car may be dropped off at any EU-Rent branch, even one that is not its scheduled drop-off branch". Necessity: Each affirmation is a proposition that another proposition is a possibility or a permissibility. Necessity: No rule is an affirmation. Necessity: No admonition is an affirmation. On PDF pages 178-179 A.2.3.3 What 'Practicable' Means All business rules (and affirmations and admonitions as well) need to be practicable. Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. If an operative business rule is practicable, a person who knows about it can decide directly whether it is being followed when that person observes relevant behavior. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. If a structural rule is practicable, a person who knows about it can also decide directly whether it is being followed when that person observes some relevant outcome from a decision or calculation. A practicable business rule is also always free of any indefinite reference to people (e.g., "you", "me"), places (e.g., "here"), and time (e.g., "now"). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to "tell" time), and (b) external clarification. All these criteria assume that the person understands the business concepts that underlie the business rule. A practicable business rule always imparts ready-to-apply knowledge of the kinds above 'on top' of such concepts. An important best practice for business rules, following naturally from this, is that the underlying business vocabulary/ies must be well developed and well managed. Specifically, each business concept should: o Be individually well defined. o Fit logically into the overall structure of concepts. o Made available to the person in appropriate manner. In addition, each business rule should be directly expressible in the given business vocabulary/ies. These best practices point toward the essential role of business vocabularies in supporting business rules . indeed, the bulk of SBVR is devoted to that area. A.2.3.4 Business Rules that Cannot Be Automated Just because business rules are practicable, this does not imply they are always automatable. Many business rules, especially operative business rules, are not automatable in IT systems. For instance, consider the obligation example given above. This distinction is not important within SBVR, which focuses on rules only from the business perspective, regardless of whether the rules could be automated. However, it is obviously important in defining a transformation from business model to PIM. In particular, non-automatable business rules need to be implemented as user activity, supported by procedure manuals or rulebooks. 12 Business Rules _____________________________________________________ Vocabulary for Describing Business Rules Speech Community: English Synonymous Form: Vocabulary for Describing Business Vocabulary _____________________________________________________ 12.1 Categories of Guidance Figure 12.1 ___________________________________________________________________ This diagram is not normative abstract syntax for SBVR, but is for illustration only. ___________________________________________________________________ 12.1.1 Guidance element of guidance · means that guides, defines or constrains some aspect of an enterprise Categorization Scheme: This sense of 'means' (as in 'ends and means', rather than 'is meant as') arises from the Business Motivation Model [BMM]. Categorization Scheme: The formulation of an element of guidance is under an enterprise.s control by a party authorized to manage, control or regulate the enterprise, by selection from alternatives in response to a combination of assessments. element of guidance is practicable Synonym: characteristic · the element of guidance is sufficiently detailed and precise that a person who knows the element of guidance can apply it effectively and consistently in relevant circumstances to know what behavior is acceptable or not, or how something is decided or calculated Categorization Scheme: The sense intended is: "It's actually something you can put to use or apply." Categorization Scheme: The behavior, decision or calculation can be that person's own. Categorization Scheme: Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. Categorization Scheme: A practicable business rule is also always free of any indefinite reference to people (e.g., "you", "me"), places (e.g., "here"), and time (e.g., "now"). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to "tell" time), and (b) external clarification. directive · official or authoritative instruction involving the management or guidance of operations Necessity: element of guidance See: an official or authoritative instruction [NODE] directive is actionable · the directive is able to be done or acted upon; is practicable Synonym: characteristic Categorization Scheme: 'Actionable' means that a person who knows about the directive could observe a relevant situation (including his or her own behavior) and decide directly whether or not the business was complying with the directive. Dictionary Basis: Each directive that is actionable is practicable. Dictionary Basis: A directive that is not actionable is not practicable. business policy · directive that is not actionable whose purpose is to guide an enterprise Categorization Scheme: Compared to a Business Rule, a Business Policy tends to be: - less structured - less discrete or not atomic - less carefully expressed in terms of standard vocabulary - not directly actionable. See: definite course or method of action selected (as by a government, institution, group, or individual) from among alternatives and in the light of given conditions to guide and usually determine present and future decisions [MWUD "Policy" 5a] Dictionary Basis: No business policy is an operative business rule. General Concept: The policy expressed as "A prisoner is considered to be on a hunger strike after missing several meals in a row." proposition is based on fact type · the proposition is formulated using the fact type General Concept: The EU-Rent business rule that is expressed as "It is obligatory that each rental specifies a car group." (or, in RuleSpeak, "A rental must have a car group.") is based on the EU-Rent fact type 'rental specifies car group'. body of shared guidance · all of the elements of guidance within a body of shared meanings On PDF page 139 body of shared meanings includes body of shared guidance body of shared guidance includes element of guidance 12.1.2 Rules rule · element of guidance that is practicable and that is a proposition that introduces an obligation or a necessity Necessity: element of guidance, proposition See: one of a set of explicit or understood regulations or principles governing conduct or procedure within a particular area of activity. a law or principle that operates within a particular sphere of knowledge, describing or prescribing what is possible or allowable. [ODE] [per proposed resolution to Issue 9579] business rule · rule that is under business jurisdiction business rule is derived from business policy Reference Scheme: business policy is basis for business rule structural rule · rule that is intended as a definitional criterion Dictionary Basis: Each structural rule is a proposition that another proposition is a necessity. URI: definitional rule definitional rule See: structural rule structural business rule · structural rule that is a business rule URI: definitional business rule definitional business rule See: structural business rule operative business rule · business rule that is intended to produce an appropriate or designed effect · business rule that covers conduct, action, practice, or procedure within a particular activity or sphere · business rule that there is an obligation concerning conduct, action, practice or procedure Necessity: business rule, directive See: a prescribed, suggested, or self-imposed guide for conduct or action : a regulation or principle [.] [MWU (1a) 'rule'] See: a prescribed guide for conduct or action [MWCD 'rule'] Dictionary Basis: Each operative business rule is a proposition that another proposition is an obligation. Dictionary Basis: No operative business rule is a structural business rule. URI: behavioral business rule behavioral business rule See: operative business rule 12.1.3 Enforcement level of enforcement · something that represents a position in a graded or ordered scale of values that specifies the severity of action imposed in order to put or keep an operative business rule in force See: a position on a real or imaginary scale of amount, quantity, extent, or quality [NODE 'level'] On PDF page 140 See: compel observance of or compliance with [NODE 'enforcement'] General Concept: An example set of levels of enforcement, based on [BRG-ODP] Enforcement Level: strict Description: strictly enforced (If you violate the rule, you cannot escape the penalty.) Enforcement Level: deferred Description: deferred enforcement (Strictly enforced, but enforcement may be delayed . e.g., waiting for resource with required skills.) Enforcement Level: pre-authorized Description: pre-authorized override (Enforced, but exceptions allowed, with prior approval for actors with before-the-fact override authorization.) Enforcement Level: post-justified Description: post-justified override (If not approved after the fact, you may be subject to sanction or other consequences.) Enforcement Level: override Description: override with explanation (Comment must be provided when the violation occurs.) Enforcement Level: guideline Description: guideline (suggested, but not enforced.) operative business rule has level of enforcement 12.1.4 Admonitions and Affirmations admonition · element of guidance that is practicable and that is a proposition that there is not an obligation or necessity where, by custom or practice, one might be assumed Necessity: element of guidance, proposition Categorization Scheme: The purpose of an admonition is to preempt application of "rules" that might be assumed by some members of a semantic community, but are not actually rules admitted by the community. Often, the reason for this assumption in a business is that other, similar, businesses have such rules. Typically, the reason for an explicit admonition is that people in the business have mistakenly applied the non-existent "rule" in the past. General Concept: (In a bank) There is no rule that a person must be over some given age in order open a savings account: "There is no minimum age for opening a savings account". General Concept: (In EU-Rent) There is no rule that a rented car can be dropped off only at the return branch specified in the rental agreement: "At the end of a rental, a rental car can be dropped off at any EU-Rent branch". There is a related rule that if the drop-off branch is not the specified return branch, the rental will incur a penalty charge, but the importance of this admonition is that EU-Rent wants its cars back, even if they are in the wrong places. It does not want a branch to refuse to accept a car on the grounds that it is not the specified return branch. On PDF page 141 Dictionary Basis: Each admonition is a proposition that another proposition is not an obligation or a necessity. Dictionary Basis: No rule is an admonition. affirmation · element of guidance that is practicable and that is a proposition that there is a permissibility or possibility where, by custom or practice, one might not be assumed Necessity: element of guidance, proposition General Concept: (In a bank) "It is possible that an account balance is negative". General Concept: (In EU-Rent) "A rental car may be dropped off at any EU-Rent branch, even one that is not its scheduled drop-off branch". Dictionary Basis: Each affirmation is a proposition that another proposition is a possibility or a permissibility. Dictionary Basis: No rule is an affirmation. Dictionary Basis: No admonition is an affirmation. On PDF pages 178-179 A.2.3.3 What 'Practicable' Means All business rules (and affirmations and admonitions as well) need to be practicable. Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. If an operative business rule is practicable, a person who knows about it can decide directly whether it is being followed when that person observes relevant behavior. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. If a structural rule is practicable, a person who knows about it can also decide directly whether it is being followed when that person observes some relevant outcome from a decision or calculation. A practicable business rule is also always free of any indefinite reference to people (e.g., "you", "me"), places (e.g., "here"), and time (e.g., "now"). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to "tell" time), and (b) external clarification. All these criteria assume that the person understands the business concepts that underlie the business rule. A practicable business rule always imparts ready-to-apply knowledge of the kinds above 'on top' of such concepts. An important best practice for business rules, following naturally from this, is that the underlying business vocabulary/ies must be well developed and well managed. Specifically, each business concept should: o Be individually well defined. o Fit logically into the overall structure of concepts. o Made available to the person in appropriate manner. In addition, each business rule should be directly expressible in the given business vocabulary/ies. These best practices point toward the essential role of business vocabularies in supporting business rules . indeed, the bulk of SBVR is devoted to that area. A.2.3.4 Business Rules that Cannot Be Automated Just because business rules are practicable, this does not imply they are always automatable. Many business rules, especially operative business rules, are not automatable in IT systems. For instance, consider the obligation example given above. This distinction is not important within SBVR, which focuses on rules only from the business perspective, regardless of whether the rules could be automated. However, it is obviously important in defining a transformation from business model to PIM. In particular, non-automatable business rules need to be implemented as user activity, supported by procedure manuals or rulebooks. User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 01 Aug 2006 19:40:54 -0700 Subject: Re: issue 9477 -- SBVR FTF issue From: John and Keri To: SBVR-FTF Thread-Topic: issue 9477 -- SBVR FTF issue Thread-Index: AcZSsH8Y361z8s2aQZCl3601Gbjn6hjFyUWAAAVbve8= Attached is the .eps file. - Keri On 8/1/06 5:14 PM, "Baisley, Donald E" wrote: > Issue9477.doc has the proposed resolution of 9477 that was discussed in > London. Keri provided the updated figure within the document. When she did > so, she also did us a great favor by providing Issue9477-applied.doc showing > how the changed portions of the document look with the changes applied. Thank > you Keri. > > Regards, > Don > > PS ­ Keri, do we need to also submit the figure as a separate eps file? Fig12.1CatGdnc.eps To: sbvr-ftf@omg.org Subject: RE: issue 9477 -- SBVR FTF issue X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Mark H Linehan Date: Wed, 2 Aug 2006 07:51:54 -0400 X-MIMETrack: Serialize by Router on D01ML083/01/M/IBM(Release 7.0.1FP1 HF1|June 27, 2006) at 08/02/2006 07:51:55, Serialize complete at 08/02/2006 07:51:55 This text is confusing in several respects: * Section A.2.3.3 discusses the possibility that operative and structural rules may or may not be practicable. Specifically, it says "If an operative business rule is practicable, ..." and also "If a structural rule is practicable, ...." But rules are supposed to be practicable by definition. The text should be revised to avoid raising the possibility that a rule may not be practicable. * More importantly, what justifies the additional complexity of having both actionable and practicable? They seem to describe almost the same thing. Going further, what justifies having both directive and element of guidance? It seems to me that you could simplify this section a lot by eliminating what look like redundant concepts. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com "Baisley, Donald E" 08/01/2006 08:14 PM To cc Subject RE: issue 9477 -- SBVR FTF issue Issue9477.doc has the proposed resolution of 9477 that was discussed in London. Keri provided the updated figure within the document. When she did so, she also did us a great favor by providing Issue9477-applied.doc showing how the changed portions of the document look with the changes applied. Thank you Keri. Regards, Don PS . Keri, do we need to also submit the figure as a separate eps file? [attachment "Issue9477.doc" deleted by Mark H Linehan/Watson/IBM] [attachment "Issue9477-applied.doc" deleted by Mark H Linehan/Watson/IBM] User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 02 Aug 2006 07:11:01 -0700 Subject: Re: issue 9477 -- SBVR FTF issue From: John and Keri To: Mark H Linehan , SBVR-FTF Thread-Topic: issue 9477 -- SBVR FTF issue Thread-Index: Aca2PXugueoCAyIwEdu4QAARJM+Cgg== Mark, I share your concerns for the unnecessary complexity that this part of the model is taking on. Even as I drew up the .consensus. model, I was sketching my own, simplified views on the side. Here are three, from most basic to a bit more elaborate (depending on how many split hairs a person requires): 1A) the most basic ... what I would use to explain the world of BUSINESS RULE to a newbie. 1B) showing an explicit .structural rule. (if needed to be made explicit ... but what is a .rule. that might be relevant to this context that is not also .structural.?) 1C) showing a common generalization of .rule. and .directive. if there is a need to include .rules. (that are not business rules) in a community.s body of shared guidance, and to do so via a more general concept. As an aside, all of these views remove the looming issue of how to reconcile to BMM. regards, Keri On 8/2/06 4:51 AM, "Mark H Linehan" wrote: This text is confusing in several respects: * Section A.2.3.3 discusses the possibility that operative and structural rules may or may not be practicable. Specifically, it says "If an operative business rule is practicable, ..." and also "If a structural rule is practicable, ...." But rules are supposed to be practicable by definition. The text should be revised to avoid raising the possibility that a rule may not be practicable. * More importantly, what justifies the additional complexity of having both actionable and practicable? They seem to describe almost the same thing. Going further, what justifies having both directive and element of guidance? It seems to me that you could simplify this section a lot by eliminating what look like redundant concepts. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com "Baisley, Donald E" 08/01/2006 08:14 PM To cc Subject RE: issue 9477 -- SBVR FTF issue Issue9477.doc has the proposed resolution of 9477 that was discussed in London. Keri provided the updated figure within the document. When she did so, she also did us a great favor by providing Issue9477-applied.doc showing how the changed portions of the document look with the changes applied. Thank you Keri. Regards, Don PS . Keri, do we need to also submit the figure as a separate eps file? [attachment "Issue9477.doc" deleted by Mark H Linehan/Watson/IBM] [attachment "Issue9477-applied.doc" deleted by Mark H Linehan/Watson/IBM] Fig12.1CatGdnc 1A.jpg Fig12.1CatGdnc 1B.jpg Fig12.1CatGdnc 1C.jpg To: sbvr-ftf@omg.org Subject: Re: issue 9477 -- SBVR FTF issue X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Mark H Linehan Date: Wed, 2 Aug 2006 11:51:58 -0400 X-MIMETrack: Serialize by Router on D01ML083/01/M/IBM(Release 7.0.1FP1 HF1|June 27, 2006) at 08/02/2006 11:51:59 Keri, I'm glad to hear that you also have concerns about this. My opinions, for what they are worth: * I'm ok with the distinction between business policy & business rule and the "actionable" concept. I think they model real world phenomena. And this distinction matches what is in BMM. * I don't see the value in distinguishing directive from element of guidance. * I don't see the value in distinguishing rule from business rule. * I don't see the value in introducing structural rule as a separate concept. * Distinguishing operative business rules from structural business rules is necessary to make it clear that level of enforcement only applies to the former. * There is something wrong with the definition of operative and structural business rules, affirmations, and admonitions. The aspect related to affirmations and admonitions is being addressed in other threads, so I won't discuss it here. * Structural business rules are defined in terms of necessities. What about business rules written in the form of impossibilities, such as "It is impossible that a person is an ancestor of himself"? (Also, why is there no definition of "impossibility"?) * Operative business rules are defined in terms of obligations. What about business rules written in the form of prohibitions, such as "It is prohibited that a person marries a first cousin"? * Similarly with operative business rules: what about a rule embedding a prohibition, such as "It is prohibited that a person marries his first cousin"? According to one definition, an operative business rule is a "business rule that there is an obligation ...." Chapter 10 distinguishes obligations and prohibitions, leading one to conclude that a business rule based on a prohibition is not an operative business rule. I don't think that's what is intended. * Section 12.2 (Statements of Guidance) mostly parallels section 12.1. There must be a better way of stating the basic point: that every rule can be expressed. As given, it's verbose without adding much value. Why does SBVR need to categorize both the meaning and the expression sides of rules? -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com John and Keri 08/02/2006 10:11 AM To Mark H Linehan/Watson/IBM@IBMUS, SBVR-FTF cc Subject Re: issue 9477 -- SBVR FTF issue Mark, I share your concerns for the unnecessary complexity that this part of the model is taking on. Even as I drew up the .consensus. model, I was sketching my own, simplified views on the side. Here are three, from most basic to a bit more elaborate (depending on how many split hairs a person requires): 1A) the most basic ... what I would use to explain the world of BUSINESS RULE to a newbie. 1B) showing an explicit .structural rule. (if needed to be made explicit ... but what is a .rule. that might be relevant to this context that is not also .structural.?) 1C) showing a common generalization of .rule. and .directive. if there is a need to include .rules. (that are not business rules) in a community.s body of shared guidance, and to do so via a more general concept. As an aside, all of these views remove the looming issue of how to reconcile to BMM. regards, Keri On 8/2/06 4:51 AM, "Mark H Linehan" wrote: This text is confusing in several respects: * Section A.2.3.3 discusses the possibility that operative and structural rules may or may not be practicable. Specifically, it says "If an operative business rule is practicable, ..." and also "If a structural rule is practicable, ...." But rules are supposed to be practicable by definition. The text should be revised to avoid raising the possibility that a rule may not be practicable. * More importantly, what justifies the additional complexity of having both actionable and practicable? They seem to describe almost the same thing. Going further, what justifies having both directive and element of guidance? It seems to me that you could simplify this section a lot by eliminating what look like redundant concepts. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com "Baisley, Donald E" 08/01/2006 08:14 PM To cc Subject RE: issue 9477 -- SBVR FTF issue Issue9477.doc has the proposed resolution of 9477 that was discussed in London. Keri provided the updated figure within the document. When she did so, she also did us a great favor by providing Issue9477-applied.doc showing how the changed portions of the document look with the changes applied. Thank you Keri. Regards, Don PS . Keri, do we need to also submit the figure as a separate eps file? [attachment "Issue9477.doc" deleted by Mark H Linehan/Watson/IBM] [attachment "Issue9477-applied.doc" deleted by Mark H Linehan/Watson/IBM] Fig12.1CatGdnc 1A1.jpg Fig12.1CatGdnc 1B1.jpg Fig12.1CatGdnc 1C1.jpg User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 02 Aug 2006 10:10:50 -0700 Subject: Re: issue 9477 -- SBVR FTF issue From: John and Keri To: Mark H Linehan , SBVR-FTF Thread-Topic: issue 9477 -- SBVR FTF issue Thread-Index: Aca2Vppf2R2iWiJJEduPRgARJM+Cgg== On 8/2/06 8:51 AM, "Mark H Linehan" wrote: Keri, I'm glad to hear that you also have concerns about this. My opinions, for what they are worth: * I'm ok with the distinction between business policy & business rule and the "actionable" concept. I think they model real world phenomena. And this distinction matches what is in BMM. I agree. (And for those who are troubled by the .action. part of .actionable., which is where this Issue all started, I made the simple suggestion/compromise of .is practicable. as a synonymous form. However, the definition of .is actionable. from BMM seems to be very simple and clear about where the .action. comes into play.) * I don't see the value in distinguishing directive from element of guidance. Probably not (which is why I omitted it). It also helps with the .fit. to BMM. * I don't see the value in distinguishing rule from business rule. Ah, this was a major point of discussion . that there are .rules. not under business jurisdiction that can be important. This is most readily apparent in the .logics. material. * I don't see the value in introducing structural rule as a separate concept. I agree. * Distinguishing operative business rules from structural business rules is necessary to make it clear that level of enforcement only applies to the former. I agree. * There is something wrong with the definition of operative and structural business rules, affirmations, and admonitions. The aspect related to affirmations and admonitions is being addressed in other threads, so I won't discuss it here. Right . covered under another Issue. * Structural business rules are defined in terms of necessities. What about business rules written in the form of impossibilities, such as "It is impossible that a person is an ancestor of himself"? (Also, why is there no definition of "impossibility"?) Isn.t this also being covered under another Issue (thread of discussion with John Hall)? * Operative business rules are defined in terms of obligations. What about business rules written in the form of prohibitions, such as "It is prohibited that a person marries a first cousin"? And the same here? * Similarly with operative business rules: what about a rule embedding a prohibition, such as "It is prohibited that a person marries his first cousin"? According to one definition, an operative business rule is a "business rule that there is an obligation ...." Chapter 10 distinguishes obligations and prohibitions, leading one to conclude that a business rule based on a prohibition is not an operative business rule. I don't think that's what is intended. I recall this also being part of another thread. (one between Don and Ed?) * Section 12.2 (Statements of Guidance) mostly parallels section 12.1. There must be a better way of stating the basic point: that every rule can be expressed. As given, it's verbose without adding much value. Why does SBVR need to categorize both the meaning and the expression sides of rules? Making the distinction between meaning and expression is a key notion of SBVR. And there are some cases where the expression concept is not a mindless repetition of the raw meaning constructs. But for those finding it .verbose. without much value add, it is (at least) in its own sub-section. regards, X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 02 Aug 2006 12:17:10 -0500 To: "Baisley, Donald E" , From: "Ronald G. Ross" Subject: RE: issue 9477 -- SBVR FTF issue At 07:14 PM 8/1/2006, Baisley, Donald E wrote: Issue9477.doc has the proposed resolution of 9477 that was discussed in London. Keri provided the updated figure within the document. When she did so, she also did us a great favor by providing Issue9477-applied.doc showing how the changed portions of the document look with the changes applied. Thank you Keri. In today's meeting, I promised to forward 2 items about this work-up. However, they were partly to solicit Don's opinion, so I think it best if I take them off-line for now. Ron Regards, Don PS . Keri, do we need to also submit the figure as a separate eps file? Reply-To: From: "Donald Chapin" To: Subject: RE: issue 9477 -- SBVR FTF issue Date: Wed, 2 Aug 2006 18:39:07 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca2S6HMJn+xAy/UQdKsn72qqNEKPgAC0lkg Mark, Issue 9477 is focused on this: .The current notion of "actionable" falls short in several regards.. The scope of this Issue is limited to the notion of .actionable.. The points you make below are outside the scope of Issue 9447 and cannot be addressed under it. These points need to be submitted as Issues if you consider them so. The deadline for Issues has passed for this FTF. A new Issue process will begin when the Interim Specification from this FTF is published (scheduled for October 6th). Best Regards, Donald -------------------------------------------------------------------------------- From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: 02 August 2006 16:52 To: sbvr-ftf@omg.org Subject: Re: issue 9477 -- SBVR FTF issue Keri, I'm glad to hear that you also have concerns about this. My opinions, for what they are worth: * I'm ok with the distinction between business policy & business rule and the "actionable" concept. I think they model real world phenomena. And this distinction matches what is in BMM. * I don't see the value in distinguishing directive from element of guidance. * I don't see the value in distinguishing rule from business rule. * I don't see the value in introducing structural rule as a separate concept. * Distinguishing operative business rules from structural business rules is necessary to make it clear that level of enforcement only applies to the former. * There is something wrong with the definition of operative and structural business rules, affirmations, and admonitions. The aspect related to affirmations and admonitions is being addressed in other threads, so I won't discuss it here. * Structural business rules are defined in terms of necessities. What about business rules written in the form of impossibilities, such as "It is impossible that a person is an ancestor of himself"? (Also, why is there no definition of "impossibility"?) * Operative business rules are defined in terms of obligations. What about business rules written in the form of prohibitions, such as "It is prohibited that a person marries a first cousin"? * Similarly with operative business rules: what about a rule embedding a prohibition, such as "It is prohibited that a person marries his first cousin"? According to one definition, an operative business rule is a "business rule that there is an obligation ...." Chapter 10 distinguishes obligations and prohibitions, leading one to conclude that a business rule based on a prohibition is not an operative business rule. I don't think that's what is intended. * Section 12.2 (Statements of Guidance) mostly parallels section 12.1. There must be a better way of stating the basic point: that every rule can be expressed. As given, it's verbose without adding much value. Why does SBVR need to categorize both the meaning and the expression sides of rules? -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com John and Keri 08/02/2006 10:11 AM To Mark H Linehan/Watson/IBM@IBMUS, SBVR-FTF cc Subject Re: issue 9477 -- SBVR FTF issue Mark, I share your concerns for the unnecessary complexity that this part of the model is taking on. Even as I drew up the .consensus. model, I was sketching my own, simplified views on the side. Here are three, from most basic to a bit more elaborate (depending on how many split hairs a person requires): 1A) the most basic ... what I would use to explain the world of BUSINESS RULE to a newbie. 1B) showing an explicit .structural rule. (if needed to be made explicit ... but what is a .rule. that might be relevant to this context that is not also .structural.?) 1C) showing a common generalization of .rule. and .directive. if there is a need to include .rules. (that are not business rules) in a community.s body of shared guidance, and to do so via a more general concept. As an aside, all of these views remove the looming issue of how to reconcile to BMM. regards, Keri On 8/2/06 4:51 AM, "Mark H Linehan" wrote: This text is confusing in several respects: * Section A.2.3.3 discusses the possibility that operative and structural rules may or may not be practicable. Specifically, it says "If an operative business rule is practicable, ..." and also "If a structural rule is practicable, ...." But rules are supposed to be practicable by definition. The text should be revised to avoid raising the possibility that a rule may not be practicable. * More importantly, what justifies the additional complexity of having both actionable and practicable? They seem to describe almost the same thing. Going further, what justifies having both directive and element of guidance? It seems to me that you could simplify this section a lot by eliminating what look like redundant concepts. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com "Baisley, Donald E" 08/01/2006 08:14 PM To cc Subject RE: issue 9477 -- SBVR FTF issue Issue9477.doc has the proposed resolution of 9477 that was discussed in London. Keri provided the updated figure within the document. When she did so, she also did us a great favor by providing Issue9477-applied.doc showing how the changed portions of the document look with the changes applied. Thank you Keri. Regards, Don PS . Keri, do we need to also submit the figure as a separate eps file? [attachment "Issue9477.doc" deleted by Mark H Linehan/Watson/IBM] [attachment "Issue9477-applied.doc" deleted by Mark H Linehan/Watson/IBM] Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 03 Aug 2006 07:46:08 -0700 Subject: Re: issue 9477 -- SBVR FTF issue From: John and Keri To: SBVR-FTF Thread-Topic: issue 9477 -- SBVR FTF issue Thread-Index: AcZSsH8Y361z8s2aQZCl3601Gbjn6hjFyUWAAFD6b2s= Issue9477-B.doc is an alternative proposed resolution of 9477 that reflects what was discussed in London. It avoids introduction of some things that will cause problems for BMM. The .eps is also attached. Issue9477-B-applied.doc shows how the changed portions of the document look with the changes applied. regards, Keri Issue9477-B.doc Fig12.1CatGdnc-B.eps Issue9477-B-applied.doc Disposition: Resolved OMG Issue No: 9477 Title: Actionable Source: Ron Ross Summary: The current notion of "actionable" falls short in several regards: * It does not take into account structural (definitional) rules. * Its wording is based on "complying", which is only appropriate for operative (behavioral) rules. * It fails to address the issue of lexical indexicals -- conversational references to person, place and time. Resolution: Make separate fact types for .is practicable. and .is actionable.. Rearrange the generalization hierarchy in 12.1 to better represent commonly understood usage of terms. Add further explanation to Annex A. Revised Text: Replace Figure 12.1 on page 137 with the following: In 12.1.1 on page 138 replace the entire entry for .directive. with the following: directive See: element of guidance In 12.1.1 on page 138 make the following changes to the entry for .directive is actionable.: 1. Replace the term .directive. with .element of guidance. in the form of expression so that it becomes .element of guidance is actionable.. 2. Add the following definition at the front. Definition: the element of guidance is able to be done or acted upon; is practicable 3. In the first Note, change the 2 uses of 'directive' to 'element of guidance', 4. Remove the two .Dictionary Basis:. lines. 5. Drop the Note at the end that reads: The sense intended is: .It.s actually something you can put to use or apply.. 6. Add the following two Necessities at the end: Necessity: Each element of guidance that is actionable is practicable. Necessity: An element of guidance that is not actionable is not practicable. In 12.1.1 on page 138 make the following changes to the entry for .element of guidance.: 1. Replace the Definition with the following: Definition: means that guides, defines or constrains some aspect of an enterprise 2. Delete the Necessity. 3. Add the following Note: Note: This sense of .means. (as in .ends and means., rather than .is meant as.) arises from the Business Motivation Model [BMM]. 4. Put the following Note (previously given for .directive.) at the end of the entry for .element of guidance.: Note: The formulation of an element of guidance is under an enterprise.s control by a party authorized to manage, control or regulate the enterprise, by selection from alternatives in response to a combination of assessments. 5. Add the following Synonym: Synonym: directive To 12.1.1 add the following new entry: element of guidance is practicable Concept Type: characteristic Definition: the element of guidance is sufficiently detailed and precise that a person who knows the element of guidance can apply it effectively and consistently in relevant circumstances to know what behavior is acceptable or not, or how something is decided or calculated Dictionary Basis: able to be done or put into practice successfully; able to be used, useful [ODE] Note: The sense intended is: .It.s actually something you can put to use or apply.. Note: The behavior, decision, or calculation can be that person.s own. Note: Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. Note: A practicable business rule is also always free of any indefinite reference to people (e.g., .you., .me.), places (e.g., .here.), and time (e.g., .now.). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to .tell. time), and (b) external clarification. In 12.1.1 on page 138 make the following changes to the entry for .business policy.: 1. Replace the Definition with the following: Definition: element of guidance that is not actionable whose purpose is to guide an enterprise 2. At the end of the entry, add the following Necessities and Example: Necessity: No business policy is a business rule. Example: The policy expressed as "A prisoner is considered to be on a hunger strike after missing several meals in a row." In 12.1.1 on page 138 in make the following changes to the entry .element of guidance is based on fact type.: 1. Replace the term .element of guidance. with .proposition. in the form of expression so that it becomes .proposition is based on fact type.. 2. In the Definition, replace .element of guidance. with .proposition.. 3. In the Example, replace .element of guidance (business rule). with .business rule.. In 12.1.1 place the entries in the following order: body of shared guidance body of shared meanings includes body of shared guidance element of guidance directive body of shared guidance includes element of guidance element of guidance is practicable element of guidance is actionable business policy proposition is based on fact type In 12.1.2 on page 139 in the entry for .rule. replace the definition: Definition: proposition that introduces an obligation or a necessity In 12.1.2 on page 139 in the entry for .structural business rule. add the following Necessity before the Synonym: Necessity: Each structural business rule is practicable. In 12.1.2 on page 139 in the entry for .operative business rule. add the following Necessity before the Synonym: Necessity: Each operative business rule is actionable. In 12.1.4 on page 140-1 in the entry for .admonition. make the following changes: 1. Replace the Definition with the following: Definition: element of guidance that is practicable and that is a proposition that there is not an obligation or necessity where, by custom or practice, one might be assumed 2. Add the following General Concept after the definition: General Concept: element of guidance, proposition 3. Remove the first Necessity (the one that reads: Each admonition is a proposition that another proposition is not an obligation or a necessity.). 4. Add the following Necessities after the final current Necessity: Necessity: No business policy is an admonition. Necessity: No business rule is an admonition. In 12.1.4 on page 141 in the entry for .affirmation. make the following changes: 1. Replace the Definition with the following: Definition: element of guidance that is practicable and that is a proposition that there is a permissibility or possibility where, by custom or practice, one might not be assumed 2. Add the following General Concept after the definition: General Concept: element of guidance, proposition 3. Remove the first Necessity (the one that reads: Each affirmation is a proposition that another proposition is a possibility or a permissibility.). 4. Add the following Necessities after the final current Necessity: Necessity: No business policy is an affirmation. Necessity: No business rule is an affirmation. Replace section A.2.3.3 with the following two sections. Note that the second section is a slightly modified version of the last two paragraphs of the original A.2.3.3. [Note: This needs the wording changes that were discussed/agreed in the Aug. 2 telcon.] A.2.3.3 What 'Practicable' Means All business rules (and affirmations and admonitions as well) need to be practicable. Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. If an operative business rule is practicable, a person who knows about it can decide directly whether it is being followed when that person observes relevant behavior. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. If a structural rule is practicable, a person who knows about it can also decide directly whether it is being followed when that person observes some relevant outcome from a decision or calculation. A practicable business rule is also always free of any indefinite reference to people (e.g., .you., .me.), places (e.g., .here.), and time (e.g., .now.). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to .tell. time), and (b) external clarification. All these criteria assume that the person understands the business concepts that underlie the business rule. A practicable business rule always imparts ready-to-apply knowledge of the kinds above .on top. of such concepts. An important best practice for business rules, following naturally from this, is that the underlying business vocabulary/ies must be well developed and well managed. Specifically, each business concept should: o Be individually well defined. o Fit logically into the overall structure of concepts. o Made available to the person in appropriate manner. In addition, each business rule should be directly expressible in the given business vocabulary/ies. These best practices point toward the essential role of business vocabularies in supporting business rules . indeed, the bulk of SBVR is devoted to that area. A.2.3.4 Business Rules that Cannot Be Automated Just because business rules are practicable, this does not imply they are always automatable. Many business rules, especially operative business rules, are not automatable in IT systems. For instance, consider the obligation example given above. This distinction is not important within SBVR, which focuses on rules only from the business perspective, regardless of whether the rules could be automated. However, it is obviously important in defining a transformation from business model to PIM. In particular, non-automatable business rules need to be implemented as user activity, supported by procedure manuals or rulebooks. Disposition: Resolved 12 Business Rules _____________________________________________________ Vocabulary for Describing Business Rules Language: English Included Vocabulary: Vocabulary for Describing Business Vocabulary _____________________________________________________ 12.1 Categories of Guidance Figure 12.1 ___________________________________________________________________ This diagram is not normative abstract syntax for SBVR, but is for illustration only. ___________________________________________________________________ 12.1.1 Guidance body of shared guidance Definition: all of the elements of guidance within a body of shared meanings body of shared meanings includes body of shared guidance element of guidance Definition: means that guides, defines or constrains some aspect of an enterprise Note: This sense of 'means' (as in 'ends and means', rather than 'is meant as') arises from the Business Motivation Model [BMM]. Note: The formulation of an element of guidance is under an enterprise.s control by a party authorized to manage, control or regulate the enterprise, by selection from alternatives in response to a combination of assessments. Synonym: directive directive See: element of guidance body of shared guidance includes element of guidance element of guidance is practicable Concept Type: characteristic Definition: the element of guidance is sufficiently detailed and precise that a person who knows the element of guidance can apply it effectively and consistently in relevant circumstances to know what behavior is acceptable or not, or how something is decided or calculated Dictionary Basis: able to be done or put into practice successfully; able to be used, useful [ODE] Note: The sense intended is: "It's actually something you can put to use or apply." Note: The behavior, decision or calculation can be that person's own. Note: Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. Note: A practicable business rule is also always free of any indefinite reference to people (e.g., "you", "me"), places (e.g., "here"), and time (e.g., "now"). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to "tell" time), and (b) external clarification. element of guidance is actionable Definition: the element of guidance is able to be done or acted upon; is practicable Concept Type: characteristic Note: 'Actionable' means that a person who knows about the element of guidance could observe a relevant situation (including his or her own behavior) and decide directly whether or not the business was complying with the element of guidance. Necessity: Each element of guidance that is actionable is practicable. Necessity: An element of guidance that is not actionable is not practicable. business policy Definition: element of guidance that is not actionable whose purpose is to guide an enterprise Note: Compared to a Business Rule, a Business Policy tends to be: - less structured - less discrete or not atomic - less carefully expressed in terms of standard vocabulary - not directly actionable. Dictionary Basis: definite course or method of action selected (as by a government, institution, group, or individual) from among alternatives and in the light of given conditions to guide and usually determine present and future decisions [MWUD "Policy" 5a] Necessity: No business policy is a business rule. Example: The policy expressed as "A prisoner is considered to be on a hunger strike after missing several meals in a row." proposition is based on fact type Definition: the proposition is formulated using the fact type Example: The EU-Rent business rule that is expressed as "It is obligatory that each rental specifies a car group." (or, in RuleSpeak, "A rental must have a car group.") is based on the EU-Rent fact type 'rental specifies car group'. 12.1.2 Rules rule Definition: proposition that introduces an obligation or a necessity Dictionary Basis: one of a set of explicit or understood regulations or principles governing conduct or procedure within a particular area of activity. a law or principle that operates within a particular sphere of knowledge, describing or prescribing what is possible or allowable. [ODE] [per proposed resolution to Issue 9579] business rule Definition: rule that is under business jurisdiction business rule is derived from business policy Synonymous Form: business policy is basis for business rule structural rule Definition: rule that is intended as a definitional criterion Necessity: Each structural rule is a proposition that another proposition is a necessity. Synonym: definitional rule definitional rule See: structural rule structural business rule Definition: structural rule that is a business rule Synonym: definitional business rule Necessity: Each structural business rule is practicable. definitional business rule See: structural business rule operative business rule Definition: business rule that is intended to produce an appropriate or designed effect Definition: business rule that covers conduct, action, practice, or procedure within a particular activity or sphere Definition: business rule that there is an obligation concerning conduct, action, practice or procedure Dictionary Basis: a prescribed, suggested, or self-imposed guide for conduct or action : a regulation or principle [.] [MWU (1a) 'rule'] Dictionary Basis: a prescribed guide for conduct or action [MWCD 'rule'] Necessity: Each operative business rule is a proposition that another proposition is an obligation. Necessity: No operative business rule is a structural business rule. Necessity: Each operative business rule is actionable. Synonym: behavioral business rule behavioral business rule See: operative business rule 12.1.3 Enforcement level of enforcement Definition: something that represents a position in a graded or ordered scale of values that specifies the severity of action imposed in order to put or keep an operative business rule in force Dictionary Basis: a position on a real or imaginary scale of amount, quantity, extent, or quality [NODE 'level'] Dictionary Basis: compel observance of or compliance with [NODE 'enforcement'] Example: An example set of levels of enforcement, based on [BRG-ODP] Enforcement Level: strict Description: strictly enforced (If you violate the rule, you cannot escape the penalty.) Enforcement Level: deferred Description: deferred enforcement (Strictly enforced, but enforcement may be delayed . e.g., waiting for resource with required skills.) Enforcement Level: pre-authorized Description: pre-authorized override (Enforced, but exceptions allowed, with prior approval for actors with before-the-fact override authorization.) Enforcement Level: post-justified Description: post-justified override (If not approved after the fact, you may be subject to sanction or other consequences.) Enforcement Level: override Description: override with explanation (Comment must be provided when the violation occurs.) Enforcement Level: guideline Description: guideline (suggested, but not enforced.) operative business rule has level of enforcement 12.1.4 Admonitions and Affirmations admonition Definition: element of guidance that is practicable and that is a proposition that there is not an obligation or necessity where, by custom or practice, one might be assumed General Concept: element of guidance, proposition Note: The purpose of an admonition is to preempt application of "rules" that might be assumed by some members of a semantic community, but are not actually rules admitted by the community. Often, the reason for this assumption in a business is that other, similar, businesses have such rules. Typically, the reason for an explicit admonition is that people in the business have mistakenly applied the non-existent "rule" in the past. Example: (In a bank) There is no rule that a person must be over some given age in order open a savings account: "There is no minimum age for opening a savings account". Example: (In EU-Rent) There is no rule that a rented car can be dropped off only at the return branch specified in the rental agreement: "At the end of a rental, a rental car can be dropped off at any EU-Rent branch". There is a related rule that if the drop-off branch is not the specified return branch, the rental will incur a penalty charge, but the importance of this admonition is that EU-Rent wants its cars back, even if they are in the wrong places. It does not want a branch to refuse to accept a car on the grounds that it is not the specified return branch. Necessity: No rule is an admonition. Necessity: No business policy is an admonition. Necessity: No business rule is an admonition. affirmation Definition: element of guidance that is practicable and that is a proposition that there is a permissibility or possibility where, by custom or practice, one might not be assumed General Concept: element of guidance, proposition Example: (In a bank) "It is possible that an account balance is negative". Example: (In EU-Rent) "A rental car may be dropped off at any EU-Rent branch, even one that is not its scheduled drop-off branch". Necessity: Each affirmation is a proposition that another proposition is a possibility or a permissibility. Necessity: No rule is an affirmation. Necessity: No admonition is an affirmation. Necessity: No business policy is an affirmation. Necessity: No business rule is an affirmation. On PDF pages 178-179 A.2.3.3 What 'Practicable' Means All business rules (and affirmations and admonitions as well) need to be practicable. Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. If an operative business rule is practicable, a person who knows about it can decide directly whether it is being followed when that person observes relevant behavior. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. If a structural rule is practicable, a person who knows about it can also decide directly whether it is being followed when that person observes some relevant outcome from a decision or calculation. A practicable business rule is also always free of any indefinite reference to people (e.g., "you", "me"), places (e.g., "here"), and time (e.g., "now"). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to "tell" time), and (b) external clarification. All these criteria assume that the person understands the business concepts that underlie the business rule. A practicable business rule always imparts ready-to-apply knowledge of the kinds above 'on top' of such concepts. An important best practice for business rules, following naturally from this, is that the underlying business vocabulary/ies must be well developed and well managed. Specifically, each business concept should: o Be individually well defined. o Fit logically into the overall structure of concepts. o Made available to the person in appropriate manner. In addition, each business rule should be directly expressible in the given business vocabulary/ies. These best practices point toward the essential role of business vocabularies in supporting business rules . indeed, the bulk of SBVR is devoted to that area. A.2.3.4 Business Rules that Cannot Be Automated Just because business rules are practicable, this does not imply they are always automatable. Many business rules, especially operative business rules, are not automatable in IT systems. For instance, consider the obligation example given above. This distinction is not important within SBVR, which focuses on rules only from the business perspective, regardless of whether the rules could be automated. However, it is obviously important in defining a transformation from business model to PIM. In particular, non-automatable business rules need to be implemented as user activity, supported by procedure manuals or rulebooks. To: sbvr-ftf@omg.org Subject: Re: issue 9477 -- SBVR FTF issue X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Mark H Linehan Date: Thu, 3 Aug 2006 17:02:35 -0400 X-MIMETrack: Serialize by Router on D01ML083/01/M/IBM(Release 7.0.1FP1 HF1|June 27, 2006) at 08/03/2006 17:02:37, Serialize complete at 08/03/2006 17:02:37 I don't see the point of having both is practicable and is actionable given the proposed definitions. Why not solve the original issue by expanding the definition and notes for is actionable rather than adding complexity with another term? In this version, the diagram doesn't match the actual text: the diagram shows that business rule (but not rule) is a kind of element of guidance. But the actual definition of business rule doesn't say that. Also the text gives an admonition as a type of element of guidance but that relationship is missing from the diagram. And the traditional distinction that a rule or business rule is actionable or practicable is missing. Maybe an editing mistake? -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com John and Keri 08/03/2006 10:46 AM To SBVR-FTF cc Subject Re: issue 9477 -- SBVR FTF issue Issue9477-B.doc is an alternative proposed resolution of 9477 that reflects what was discussed in London. It avoids introduction of some things that will cause problems for BMM. The .eps is also attached. Issue9477-B-applied.doc shows how the changed portions of the document look with the changes applied. regards, Keri [attachment "Issue9477-B.doc" deleted by Mark H Linehan/Watson/IBM] [attachment "Fig12.1CatGdnc-B.eps" deleted by Mark H Linehan/Watson/IBM] [attachment "Issue9477-B-applied.doc" deleted by Mark H Linehan/Watson/IBM] User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 03 Aug 2006 15:12:22 -0700 Subject: Re: issue 9477 -- SBVR FTF issue From: John and Keri To: Mark H Linehan , SBVR-FTF Thread-Topic: issue 9477 -- SBVR FTF issue Thread-Index: Aca3SeR0IujivyM9EduW9AARJM+Cgg== On 8/3/06 2:02 PM, "Mark H Linehan" wrote: I don't see the point of having both is practicable and is actionable given the proposed definitions. Why not solve the original issue by expanding the definition and notes for is actionable rather than adding complexity with another term? My personal preference would be to do that. And that is what the original issue resolution proposed. But currently the majority agrees with having the two fact types, and what I have presented reflects that position. In this version, the diagram doesn't match the actual text: the diagram shows that business rule (but not rule) is a kind of element of guidance. But the actual definition of business rule doesn't say that. Good catch. I have corrected that in the documents attached to this note. Also the text gives an admonition as a type of element of guidance but that relationship is missing from the diagram. Hmmm... I was trying to minimize line crossings and to keep the figure compact. But if you are saying that I took liberties with UML and produced an incorrect (or misleading) diagram, I can try some different arrangements. In the meantime, simply envision the .admonition. box being below the horizontal subtype line. And the traditional distinction that a rule or business rule is actionable or practicable is missing. Maybe an editing mistake? Nope! That is the heart of this issue . where and what kind of characterization, now that we have the two levels of characterization. In the current .two characteristic. view, the distinction has to happen at the most specific level, i.e., at operative business rule and structural business rule. In other words, there was an objection to using .actionable. (even with its improved wording) for structural business rule so structural business rule now has the characteristic of being practicable. If you look at each of the .leaf. elements, you will see the allocation of the characteristic. ~ Keri Issue9477-Bv2.doc Issue9477-Bv2-applied.doc Disposition: Resolved OMG Issue No: 9477 Title: Actionable Source: Ron Ross Summary: The current notion of "actionable" falls short in several regards: * It does not take into account structural (definitional) rules. * Its wording is based on "complying", which is only appropriate for operative (behavioral) rules. * It fails to address the issue of lexical indexicals -- conversational references to person, place and time. Resolution: Make separate fact types for .is practicable. and .is actionable.. Rearrange the generalization hierarchy in 12.1 to better represent commonly understood usage of terms. Add further explanation to Annex A. Revised Text: Replace Figure 12.1 on page 137 with the following: In 12.1.1 on page 138 replace the entire entry for .directive. with the following: directive See: element of guidance In 12.1.1 on page 138 make the following changes to the entry for .directive is actionable.: 1. Replace the term .directive. with .element of guidance. in the form of expression so that it becomes .element of guidance is actionable.. 2. Add the following definition at the front. Definition: the element of guidance is able to be done or acted upon; is practicable 3. In the first Note, change the 2 uses of 'directive' to 'element of guidance', 4. Remove the two .Dictionary Basis:. lines. 5. Drop the Note at the end that reads: The sense intended is: .It.s actually something you can put to use or apply.. 6. Add the following two Necessities at the end: Necessity: Each element of guidance that is actionable is practicable. Necessity: An element of guidance that is not actionable is not practicable. In 12.1.1 on page 138 make the following changes to the entry for .element of guidance.: 1. Replace the Definition with the following: Definition: means that guides, defines or constrains some aspect of an enterprise 2. Delete the Necessity. 3. Add the following Note: Note: This sense of .means. (as in .ends and means., rather than .is meant as.) arises from the Business Motivation Model [BMM]. 4. Put the following Note (previously given for .directive.) at the end of the entry for .element of guidance.: Note: The formulation of an element of guidance is under an enterprise.s control by a party authorized to manage, control or regulate the enterprise, by selection from alternatives in response to a combination of assessments. 5. Add the following Synonym: Synonym: directive To 12.1.1 add the following new entry: element of guidance is practicable Concept Type: characteristic Definition: the element of guidance is sufficiently detailed and precise that a person who knows the element of guidance can apply it effectively and consistently in relevant circumstances to know what behavior is acceptable or not, or how something is decided or calculated Dictionary Basis: able to be done or put into practice successfully; able to be used, useful [ODE] Note: The sense intended is: .It.s actually something you can put to use or apply.. Note: The behavior, decision, or calculation can be that person.s own. Note: Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. Note: A practicable business rule is also always free of any indefinite reference to people (e.g., .you., .me.), places (e.g., .here.), and time (e.g., .now.). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to .tell. time), and (b) external clarification. In 12.1.1 on page 138 make the following changes to the entry for .business policy.: 1. Replace the Definition with the following: Definition: element of guidance that is not actionable whose purpose is to guide an enterprise 2. At the end of the entry, add the following Necessities and Example: Necessity: No business policy is a business rule. Example: The policy expressed as "A prisoner is considered to be on a hunger strike after missing several meals in a row." In 12.1.1 on page 138 in make the following changes to the entry .element of guidance is based on fact type.: 1. Replace the term .element of guidance. with .proposition. in the form of expression so that it becomes .proposition is based on fact type.. 2. In the Definition, replace .element of guidance. with .proposition.. 3. In the Example, replace .element of guidance (business rule). with .business rule.. In 12.1.1 place the entries in the following order: body of shared guidance body of shared meanings includes body of shared guidance element of guidance directive body of shared guidance includes element of guidance element of guidance is practicable element of guidance is actionable business policy proposition is based on fact type In 12.1.2 on page 139 in the entry for .rule. replace the definition: Definition: proposition that introduces an obligation or a necessity In 12.1.2 on page 139 in the entry for .business rule. add this General Concept line after the Definition: General Concept: element of guidance, rule In 12.1.2 on page 139 in the entry for .structural business rule. add the following Necessity before the Synonym: Necessity: Each structural business rule is practicable. In 12.1.2 on page 139 in the entry for .operative business rule. add the following Necessity before the Synonym: Necessity: Each operative business rule is actionable. In 12.1.4 on page 140-1 in the entry for .admonition. make the following changes: 1. Replace the Definition with the following: Definition: element of guidance that is practicable and that is a proposition that there is not an obligation or necessity where, by custom or practice, one might be assumed 2. Add the following General Concept after the definition: General Concept: element of guidance, proposition 3. Remove the first Necessity (the one that reads: Each admonition is a proposition that another proposition is not an obligation or a necessity.). 4. Add the following Necessities after the final current Necessity: Necessity: No business policy is an admonition. Necessity: No business rule is an admonition. In 12.1.4 on page 141 in the entry for .affirmation. make the following changes: 1. Replace the Definition with the following: Definition: element of guidance that is practicable and that is a proposition that there is a permissibility or possibility where, by custom or practice, one might not be assumed 2. Add the following General Concept after the definition: General Concept: element of guidance, proposition 3. Remove the first Necessity (the one that reads: Each affirmation is a proposition that another proposition is a possibility or a permissibility.). 4. Add the following Necessities after the final current Necessity: Necessity: No business policy is an affirmation. Necessity: No business rule is an affirmation. Replace section A.2.3.3 with the following two sections. Note that the second section is a slightly modified version of the last two paragraphs of the original A.2.3.3. [Note: This needs the wording changes that were discussed/agreed in the Aug. 2 telcon.] A.2.3.3 What 'Practicable' Means All business rules (and affirmations and admonitions as well) need to be practicable. Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. If an operative business rule is practicable, a person who knows about it can decide directly whether it is being followed when that person observes relevant behavior. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. If a structural rule is practicable, a person who knows about it can also decide directly whether it is being followed when that person observes some relevant outcome from a decision or calculation. A practicable business rule is also always free of any indefinite reference to people (e.g., .you., .me.), places (e.g., .here.), and time (e.g., .now.). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to .tell. time), and (b) external clarification. All these criteria assume that the person understands the business concepts that underlie the business rule. A practicable business rule always imparts ready-to-apply knowledge of the kinds above .on top. of such concepts. An important best practice for business rules, following naturally from this, is that the underlying business vocabulary/ies must be well developed and well managed. Specifically, each business concept should: o Be individually well defined. o Fit logically into the overall structure of concepts. o Made available to the person in appropriate manner. In addition, each business rule should be directly expressible in the given business vocabulary/ies. These best practices point toward the essential role of business vocabularies in supporting business rules . indeed, the bulk of SBVR is devoted to that area. A.2.3.4 Business Rules that Cannot Be Automated Just because business rules are practicable, this does not imply they are always automatable. Many business rules, especially operative business rules, are not automatable in IT systems. For instance, consider the obligation example given above. This distinction is not important within SBVR, which focuses on rules only from the business perspective, regardless of whether the rules could be automated. However, it is obviously important in defining a transformation from business model to PIM. In particular, non-automatable business rules need to be implemented as user activity, supported by procedure manuals or rulebooks. Disposition: Resolved User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 04 Aug 2006 08:41:01 -0700 Subject: Re: issue 9477 -- SBVR FTF issue From: John and Keri To: SBVR-FTF , Mark H Linehan Thread-Topic: issue 9477 -- SBVR FTF issue Thread-Index: Aca33GMaoWqqQiPPEduiRQARJM+Cgg== On 8/3/06 2:02 PM, "Mark H Linehan" wrote: > > I don't see the point of having both is practicable and is actionable given > the proposed definitions. Why not solve the original issue by expanding the > definition and notes for is actionable rather than adding complexity with > another term? Considering that "is actionable" has roots in BMM and I just ran across how BMM is presenting this characteristic, I wonder if we could simply use the definition for "is actionable" that BMM is using -- namely: >> the does not require additional interpretation to undertake strategies >> or tactics That seems to cover to both operative and structural business rules and would let us go back to the single, simple characteristic, with the original sense, that we had when this 'modest' (wording improvement) issue was first raised. ~ Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 10 Aug 2006 06:25:53 -0700 Subject: Re: issue 9477 -- actionable From: John and Keri To: John Hall , SBVR-FTF Thread-Topic: issue 9477 -- actionable Thread-Index: Aca8gIDWvysvEChzEduHfAARJM+Cgg== On 8/10/06 4:58 AM, "John Hall" wrote: > Suggestion for Issue 9477 attached John, Thanks for getting this out. Some initial input: pg. 2, you wrote: .Before the London meeting, business policy was a category of proposition. I don.t think this was changed during the meeting.. I have checked my notes from the work-up of this Issue. business policy was removed mid-May from being a category of proposition (as part of this Issue.s items). So it would have been part of the proposal as discussed prior to, and in, London. (That said, I do not recall the specifics . why .business policy. was felt to not qualify as a category of proposition.) pg. 5, you wrote: .The difference is that I am suggesting that directive be dropped from SBVR, rather than made into a synonym for element of guidance.. I agree with that (the removal of .directive. from SBVR and retaining only .element of guidance.). That is an improvement from the SBVR perspective. The only reason I had retained .directive. in my proposal was to aid reconciliation with BMM. Do you think that BMM would be willing to change its .directive. to be termed .element of guidance.? (IOW, do you read this change as helping or hindering the .harmony. of BMM & SBVR?) pg. 5, you wrote: .I would prefer to stay with is practicable as the delimiting characteristic, given the long discussion we had about is actionable, and whether it could apply to structural business rules.. So, to confirm -- this would result in the following characteristics: business policy ... is NOT practicable operative business rule ... is practicable structural business rule ... is practicable affirmation ... is practicable admonition ... is practicable Would you entertain a proposal to retain is actionable as a synonym (synonymous form) for is practicable? There is a legacy (and practice) issue around dropping is actionable entirely. As a secondary term this could be used by those who need it (and ignored by those who would prefer not). pg. 6, you wrote: .Is structural rule needed in SBVR? If not, the model becomes even simpler. I agree. Thanks for this suggestion. Thanks again for giving this the careful thought and clear presentation that you have. ~ Keri Date: Thu, 10 Aug 2006 15:47:11 +0100 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: John and Keri Cc: SBVR-FTF Subject: Re: issue 9477 -- actionable Keri, See comments in line John John and Keri wrote: On 8/10/06 4:58 AM, "John Hall" wrote: > Suggestion for Issue 9477 attached John, Thanks for getting this out. Some initial input: pg. 2, you wrote: .Before the London meeting, business policy was a category of proposition. I don.t think this was changed during the meeting.. I have checked my notes from the work-up of this Issue. business policy was removed mid-May from being a category of proposition (as part of this Issue.s items). So it would have been part of the proposal as discussed prior to, and in, London. (That said, I do not recall the specifics . why .business policy. was felt to not qualify as a category of proposition.) pg. 5, you wrote: .The difference is that I am suggesting that directive be dropped from SBVR, rather than made into a synonym for element of guidance.. I agree with that (the removal of .directive. from SBVR and retaining only .element of guidance.). That is an improvement from the SBVR perspective. The only reason I had retained .directive. in my proposal was to aid reconciliation with BMM. Do you think that BMM would be willing to change its .directive. to be termed .element of guidance.? (IOW, do you read this change as helping or hindering the .harmony. of BMM & SBVR?) I think we need to deal with this as a separate issue in BMM. "Actionable" grew out of a BRG discussion in BMM 1.1, about whether business policies were enforceable. We decided that they were not directly enforceable - to enforce you have to be able to detect violations, and you detect violations of the business rules that are derived from the business policies. then we used 'actionable' as the delimiting characteristic. We need to get back to this in BMM. It's especially important people using the BMM for compliance. When a regulatory auditor asks you to demonstrate compliance, you would start with the relevant regulations, show the results of assessments (including the impacts of other influencers) and then the policies formulated to address them. To show compliance you have to be able to show: enforceable rules based on the policies and their enforcement - how violations are detected, what remedial actions are taken to bring the enterprise back into compliance, and what (if any) sanctions are taken against rule violators. Then you show how this is made operational in the business processes that are governed by the policies and guided by the rules. I haven't yet worked through how this issue should be formulated for BMM, but my current idea is that directive should be in BMM (as a specialization of element of guidance, adopted from SBVR) and specialized into operational business rule (as a specialization of business rule, adopted from SBVR) and business policy, with 'directly enforceable / not directly enforceable' as the delimiting characteristic. It sounds a bit clumsy at the moment, but I'll work on it. pg. 5, you wrote: .I would prefer to stay with is practicable as the delimiting characteristic, given the long discussion we had about is actionable, and whether it could apply to structural business rules.. So, to confirm -- this would result in the following characteristics: business policy ... is NOT practicable operative business rule ... is practicable structural business rule ... is practicable affirmation ... is practicable admonition ... is practicable Would you entertain a proposal to retain is actionable as a synonym (synonymous form) for is practicable? There is a legacy (and practice) issue around dropping is actionable entirely. As a secondary term this could be used by those who need it (and ignored by those who would prefer not). I'd prefer not, given the strong feelings about what 'actionable' and 'action' mean. But there's no reason why practitioners shouldn't adopt 'actionable' as a local name in their practice. SBVR would support this really well. pg. 6, you wrote: .Is structural rule needed in SBVR? If not, the model becomes even simpler. I agree. Thanks for this suggestion. Thanks again for giving this the careful thought and clear presentation that you have. ~ Keri X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 10 Aug 2006 14:09:38 -0500 To: john.hall@modelsys.com, John and Keri From: "Ronald G. Ross" Subject: Re: issue 9477 -- actionable Cc: SBVR-FTF At 09:47 AM 8/10/2006, John Hall wrote: Keri, See comments in line I have separated this crucial issue from others, which I am sending in a separate message. pg. 5, you wrote: .The difference is that I am suggesting that directive be dropped from SBVR, rather than made into a synonym for element of guidance.. [Keri]: I agree with that (the removal of .directive. from SBVR and retaining only .element of guidance.). That is an improvement from the SBVR perspective. The only reason I had retained .directive. in my proposal was to aid reconciliation with BMM. Do you think that BMM would be willing to change its .directive. to be termed .element of guidance.? (IOW, do you read this change as helping or hindering the .harmony. of BMM & SBVR?) [John Hall] I think we need to deal with this as a separate issue in BMM. Depending on what you mean by "dealt with" I'm afraid doing that could be a showstopper for me. * There is no point to having any part of these discussions once here, and once there. That's not a productive use of time or energy. And it doesn't build confidence. * You have pointed out the need for minimum disruption on the BMM side. What could be less disruptive than saying 'the issue has been thoroughly dealt with and resolved on the SBVR side, and here is the solution'. The wise course of action is to address a complete solution for guidance that everyone buys into to, so we can all speak with one voice in the other forum. I hope that is the course we will take. Ron User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 10 Aug 2006 14:59:02 -0700 Subject: Re: issue 9477 -- actionable From: John and Keri To: John Hall CC: SBVR-FTF Thread-Topic: issue 9477 -- actionable Thread-Index: Aca8yDCCb0R1ICi7EduHfAARJM+Cgg== Keri wrote: Would you entertain a proposal to retain is actionable as a synonym (synonymous form) for is practicable? There is a legacy (and practice) issue around dropping is actionable entirely. As a secondary term this could be used by those who need it (and ignored by those who would prefer not). On 8/10/06 7:47 AM, "John Hall" wrote: I'd prefer not, given the strong feelings about what 'actionable' and 'action' mean. ~~~~~~~~~ So are you saying this is a .show-stopper. point for you? Since there are .strong feelings. in both directions, I was hoping that we could forge a compromise that would satisfy the widest range of perspectives. ~ Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 10 Aug 2006 15:14:57 -0700 Subject: Re: issue 9477 -- actionable From: John and Keri To: John Hall , "Ronald G. Ross" CC: SBVR-FTF Thread-Topic: issue 9477 -- actionable Thread-Index: Aca8ymm8qFI6RCi9EduHfAARJM+Cgg== John, If asked you only for your reading on how you would see things proceeding vis-à-vis BMM. I understand that you cannot, of course, commit to any outcome in the BMM-FTF. Would you, for example, be willing to log a BMM issue to change the BMM term .directive. to .element of guidance., contingent on the SBVR change? Ron, is this what would satisfy you? If not, what? Thanks, ~ Keri ~~~~~~~~~~~~~ Keri wrote: pg. 5, you wrote: .The difference is that I am suggesting that directive be dropped from SBVR, rather than made into a synonym for element of guidance.. [Keri]: I agree with that (the removal of .directive. from SBVR and retaining only .element of guidance.). That is an improvement from the SBVR perspective. The only reason I had retained .directive. in my proposal was to aid reconciliation with BMM. Do you think that BMM would be willing to change its .directive. to be termed .element of guidance.? (IOW, do you read this change as helping or hindering the .harmony. of BMM & SBVR?) At 09:47 AM 8/10/2006, John Hall wrote: [John Hall] I think we need to deal with this as a separate issue in BMM. On 8/10/06 12:09 PM, "Ronald G. Ross" wrote: Depending on what you mean by "dealt with" I'm afraid doing that could be a showstopper for me. * There is no point to having any part of these discussions once here, and once there. That's not a productive use of time or energy. And it doesn't build confidence. * You have pointed out the need for minimum disruption on the BMM side. What could be less disruptive than saying 'the issue has been thoroughly dealt with and resolved on the SBVR side, and here is the solution'. The wise course of action is to address a complete solution for guidance that everyone buys into to, so we can all speak with one voice in the other forum. I hope that is the course we will take. X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 10 Aug 2006 18:04:22 -0500 To: john.hall@modelsys.com, John and Keri From: "Ronald G. Ross" Subject: Re: issue 9477 -- actionable Cc: SBVR-FTF At 09:47 AM 8/10/2006, John Hall wrote: Keri, See comments in line pg. 5, you wrote: .The difference is that I am suggesting that directive be dropped from SBVR, rather than made into a synonym for element of guidance.. [Keri wrote]: I agree with that (the removal of .directive. from SBVR and retaining only .element of guidance.). That is an improvement from the SBVR perspective. The only reason I had retained .directive. in my proposal was to aid reconciliation with BMM. Do you think that BMM would be willing to change its .directive. to be termed .element of guidance.? (IOW, do you read this change as helping or hindering the .harmony. of BMM & SBVR?) [John Hall wrote]: I think we need to deal with this as a separate issue in BMM. "Actionable" grew out of a BRG discussion in BMM 1.1, about whether business policies were enforceable. That's simply not the case. I don't know what purpose it serves to go back over the history of this, but since you brought it up, allow me to set the record straight. The discussion in BRG has always been about whether business rules were 'practicable' in the sense of the current definition (of 'practicable'). Enforcement was not the issue. Your view has undoubtedly be shaped by your focus on regulatory compliance since the BRG did its work on this. [From BMM]: 'Actionable' means that a person who understands a Directive could observe a relevant situation (including his or her own behavior) and decide directly whether or not the business was complying with that Directive. A key word in that is 'complying'. ['Comply' from MWUD]: 2 : to accord or assent : conform or adapt one's actions (as to another's wishes) ['Accord' from MWUD]: 1 : to bring into agreement : RECONCILE, HARMONIZE *the scientists' conclusions seem contradictory but can be accorded by calm reasoning* So 'complying' can be construed in the sense of agreeing with, or reconciled with, or harmonized with. Decisions should agree with the outcomes prescribed by structural rules. Computations should agree with the outcomes prescribed by structural rules. That was always an entirely appropriate sense of "actionable" for the BRG (and BRS before that, where the idea originally can from). Be that as it may, the question at hand is whether we can arrive at a satisfactory resolution for both SBVR and BMM. Ron X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 10 Aug 2006 19:15:03 -0500 To: john.hall@modelsys.com, John and Keri From: "Ronald G. Ross" Subject: Re: issue 9477 -- actionable Cc: SBVR-FTF At 09:47 AM 8/10/2006, John Hall wrote: Keri, See comments in line John, On page 4 of your document, you introduce a new concept "practicable element of guidance". How would that be simplifying? Would you really consider that a natural or business-friendly signifier? Additionally, we have no practice or standard for taking a characteristic and naming a new category for all instances of categories that conform? What is the point of that? See my additional comments in line. John John and Keri wrote: On 8/10/06 4:58 AM, "John Hall" wrote: > Suggestion for Issue 9477 attached John, Thanks for getting this out. Some initial input: pg. 2, you wrote: .Before the London meeting, business policy was a category of proposition . I don.t think this was changed during the meeting.. I have checked my notes from the work-up of this Issue. business policy was removed mid-May from being a category of proposition (as part of this Issue.s items). So it would have been part of the proposal as discussed prior to, and in, London. (That said, I do not recall the specifics ­ why .business policy. was felt to not qualify as a category of proposition.) I've always thought about 'proposition' from an engineering perspective. Since a business policy isn't practicable, what's there to engineer? Perhaps correct from a logics point of view, but not very meaningful from a business point of view. pg. 5, you wrote: .The difference is that I am suggesting that directive be dropped from SBVR, rather than made into a synonym for element of guidance.. I agree with that (the removal of .directive. from SBVR and retaining only .element of guidance.). That is an improvement from the SBVR perspective. The only reason I had retained .directive. in my proposal was to aid reconciliation with BMM. Do you think that BMM would be willing to change its .directive. to be termed .element of guidance.? (IOW, do you read this change as helping or hindering the .harmony. of BMM & SBVR?) I think we need to deal with this as a separate issue in BMM. "Actionable" grew out of a BRG discussion in BMM 1.1, about whether business policies were enforceable. We decided that they were not directly enforceable - to enforce you have to be able to detect violations, and you detect violations of the business rules that are derived from the business policies. then we used 'actionable' as the delimiting characteristic. We need to get back to this in BMM. It's especially important people using the BMM for compliance. When a regulatory auditor asks you to demonstrate compliance, you would start with the relevant regulations, show the results of assessments (including the impacts of other influencers) and then the policies formulated to address them. To show compliance you have to be able to show: enforceable rules based on the policies and their enforcement - how violations are detected, what remedial actions are taken to bring the enterprise back into compliance, and what (if any) sanctions are taken against rule violators. Then you show how this is made operational in the business processes that are governed by the policies and guided by the rules. I haven't yet worked through how this issue should be formulated for BMM, but my current idea is that directive should be in BMM (as a specialization of element of guidance, adopted from SBVR) and specialized into operational business rule (as a specialization of business rule, adopted from SBVR) and business policy, with 'directly enforceable / not directly enforceable' as the delimiting characteristic. It sounds a bit clumsy at the moment, but I'll work on it. John, with all due respect, how 'unknown' does this square with the position that the BMM is stable and proven in practice, and therefore suitable for the fast track through the OMG? Are you saying that BMM has notable deficiencies? The BMM is quite good. Are you planning a re-purposing? pg. 6, you wrote: .Is structural rule needed in SBVR? If not, the model becomes even simpler. I agree. Thanks for this suggestion. I respectfully disagree. The notion of structural rule is a valid one They exist. They use vocabulary. They may need to be recorded. Ron Thanks again for giving this the careful thought and clear presentation that you have. ~ Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 10 Aug 2006 17:41:11 -0700 Subject: Re: issue 9477 -- actionable From: John and Keri To: "Ronald G. Ross" CC: SBVR-FTF Thread-Topic: issue 9477 -- actionable Thread-Index: Aca83tdyFhPBIyjSEduHfAARJM+Cgg== On 8/10/06 5:15 PM, "Ronald G. Ross" wrote: pg. 6, you wrote: .Is structural rule needed in SBVR? If not, the model becomes even simpler. I agree. Thanks for this suggestion. I respectfully disagree. The notion of structural rule is a valid one They exist. They use vocabulary. They may need to be recorded. Ron, The reason I agreed with the removal of .structural rule. is that it simply isn.t needed/used as an explicit concept in SBVR. In fact, I had this removed in one of my drafts (but left it in my alternative largely because I felt that it would raise too much ire and focus attention off of the main aspects, just as it is doing here). Frankly, I had a hard time coming up with an example of a .rule. that was not a .structural rule. -- i.e., what would the .other. category of .rule. be? So, .rule. and .structural rule. (from an SBVR perspective) seemed to be quite adequate, if/when needed. ~ Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 11 Aug 2006 06:55:26 -0700 Subject: Re: issue 9477 -- actionable From: John and Keri To: SBVR-FTF Thread-Topic: issue 9477 -- actionable Thread-Index: Aca9TcwKCnkv4ilBEduHfAARJM+Cgg== To summarize, it appears we have 4 things to agree. To save drawing yet-another variation (without better guidance, the combinations are beginning to become un-manageable!), perhaps we can address each aspect. If we can agree even a subset of these, then I can produce another draft diagram. 1) Is .business policy. a category of .proposition.? 2) Does .structural rule. need an explicit presence in SBVR? 3) Do we need .directive. in SBVR? If yes, where/what . i.e., as a specialized category of something, as a synonym of something, etc. 4) Do we need .is actionable. in SBVR? If yes, where/what . i.e., at the level of .element of guidance., as a synonym for .is practicable., etc. ~ Keri On 8/11/06 6:30 AM, "John Hall" wrote: Ron, I suggested the change to simplify the SBVR model, since "directive" and "actionable" didn't seem to play much part in SBVR. But if it's important to you - important enough for you consider using your veto power - I don't mind leaving them in SBVR. An updated diagram is attached. John Ronald G. Ross wrote: At 09:47 AM 8/10/2006, John Hall wrote: Keri, See comments in line I have separated this crucial issue from others, which I am sending in a separate message. pg. 5, you wrote: .The difference is that I am suggesting that directive be dropped from SBVR, rather than made into a synonym for element of guidance.. [Keri]: I agree with that (the removal of .directive. from SBVR and retaining only .element of guidance.). That is an improvement from the SBVR perspective. The only reason I had retained .directive. in my proposal was to aid reconciliation with BMM. Do you think that BMM would be willing to change its .directive. to be termed .element of guidance.? (IOW, do you read this change as helping or hindering the .harmony. of BMM & SBVR?) [John Hall] I think we need to deal with this as a separate issue in BMM. Depending on what you mean by "dealt with" I'm afraid doing that could be a showstopper for me. * There is no point to having any part of these discussions once here, and once there. That's not a productive use of time or energy. And it doesn't build confidence. * You have pointed out the need for minimum disruption on the BMM side. What could be less disruptive than saying 'the issue has been thoroughly dealt with and resolved on the SBVR side, and here is the solution'. The wise course of action is to address a complete solution for guidance that everyone buys into to, so we can all speak with one voice in the other forum. I hope that is the course we will take. Ron Date: Fri, 11 Aug 2006 14:30:19 +0100 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: "Ronald G. Ross" Cc: John and Keri , SBVR-FTF Subject: Re: issue 9477 -- actionable Ron, I suggested the change to simplify the SBVR model, since "directive" and "actionable" didn't seem to play much part in SBVR. But if it's important to you - important enough for you consider using your veto power - I don't mind leaving them in SBVR. An updated diagram is attached. John Ronald G. Ross wrote: At 09:47 AM 8/10/2006, John Hall wrote: Keri, See comments in line I have separated this crucial issue from others, which I am sending in a separate message. pg. 5, you wrote: .The difference is that I am suggesting that directive be dropped from SBVR, rather than made into a synonym for element of guidance.. [Keri]: I agree with that (the removal of .directive. from SBVR and retaining only .element of guidance.). That is an improvement from the SBVR perspective. The only reason I had retained .directive. in my proposal was to aid reconciliation with BMM. Do you think that BMM would be willing to change its .directive. to be termed .element of guidance.? (IOW, do you read this change as helping or hindering the .harmony. of BMM & SBVR?) [John Hall] I think we need to deal with this as a separate issue in BMM. Depending on what you mean by "dealt with" I'm afraid doing that could be a showstopper for me. * There is no point to having any part of these discussions once here, and once there. That's not a productive use of time or energy. And it doesn't build confidence. * You have pointed out the need for minimum disruption on the BMM side. What could be less disruptive than saying 'the issue has been thoroughly dealt with and resolved on the SBVR side, and here is the solution'. The wise course of action is to address a complete solution for guidance that everyone buys into to, so we can all speak with one voice in the other forum. I hope that is the course we will take. Ron SBVR Issue 9477 JH060811.doc User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 11 Aug 2006 07:12:52 -0700 Subject: Re: issue 9477 -- actionable From: John and Keri To: SBVR-FTF Thread-Topic: issue 9477 -- actionable Thread-Index: Aca9TcwKCnkv4ilBEduHfAARJM+CggAAm934 Here is my input on these 4 points. ~ Keri On 8/11/06 6:55 AM, "John and Keri" wrote: To summarize, it appears we have 4 things to agree. To save drawing yet-another variation (without better guidance, the combinations are beginning to become un-manageable!), perhaps we can address each aspect. If we can agree even a subset of these, then I can produce another draft diagram. 1) Is .business policy. a category of .proposition.? I don.t care. But letting it be treated as such does appear to produce a neater (more tidy) set of concepts. 2) Does .structural rule. need an explicit presence in SBVR? No. It is currently only made explicit so that .rule. can be presented as an abstract type. If we treat .rule. as permitting instances then any instances of .rule that is not a business rule. that someone might need can simply live there. Its omission does produce a cleaner model -- but if this is someone(s).s passion then I don.t care that much (not the hill I want to die on). 3) Do we need .directive. in SBVR? If yes, where/what . i.e., as a specialized category of something, as a synonym of something, etc. I would only want to retain it as a synonym for .element of guidance. -- i.e., for alignment with BMM. I would not want to have a separate concept because that would then suggest that the BMM.s generalization of .business policy. and .business rule. (currently mis-termed .directive.) will be used to argue that BMM.s sense of .business rule. omits .structural business rule.. (FWIW, this is my hill to die on.) 4) Do we need .is actionable. in SBVR? If yes, where/what . i.e., at the level of .element of guidance., as a synonym for .is practicable., etc. I prefer only one fact type. I strongly prefer retaining .is actionable. as a secondary (synonymous form) term for .is practicable.. I have legacy material that would be helped, in the transition, by having the provenance appear in SBVR. However, showing it as separate fact types is the worst of all worlds. ~ Keri Date: Thu, 10 Aug 2006 12:58:03 +0100 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: Donald.Chapin@btinternet.com Cc: sbvr-ftf@omg.org Subject: Re: [SBVR-FTF] -- Next Telephone Meeting - Friday, August 11th , at 14:30 GMT (see local times) Suggestion for Issue 9477 attached John Donald Chapin wrote: Team -- The next telephone meeting of the SBVR Finalization Task Force will take place on Friday, August 11th, at 14:30 GMT (see local times below) NOTE: The cut-off for material to be discussed in this meeting is Thursday, Sept 10th at Noon Pacific Daylight Time Agenda 1. Admin a. Scribe responsibility b. New Agenda Items c. Minutes of last meeting d. Next Meeting e. SBVR FTF Matters - none f. Pending Actions - none 2. Release Issue Resolutions for Vote - Issue 9477 - Issue 9613 - any other Issue Resolution editing instructions that come in 3. Triage new SBVR Issues (not Deferred) - none 4. Bring open Issues to agreement - 9257 - other Issues ready for discussion Future Topics - How SBVR SE and SBVR Vocabulary map to each other - SBVR Press Release Donald This SBVR Finalization Task Force meeting is at 14:30 GMT, which is (during daylight savings time): 16:30 in Continental Western Europe 15:30 in UK 10:30 in US East 9:30 in US Central 8:30 in US Mountain 7:30 in US Pacific The call-in phone numbers for the meeting, courtesy of Unisys, are: Toll Free for US: 1-877-302-3764 Local call for UK: 0190 821 2068 Local call for Belgium: 32 27 28 0521 Local call for the Netherlands: 31 20 526 7978 Local call for Switzerland: +41 1723 3815 Unisys employees: Net820-7139 Meeting access code: 380 6382 SBVR Issue 9477 JH060810.doc User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Fri, 11 Aug 2006 13:38:16 -0700 Subject: Re: issue 9477 -- clarification on ability to discriminate From: John and Keri To: John Hall , SBVR-FTF Thread-Topic: issue 9477 -- clarification on ability to discriminate Thread-Index: Aca9hhJ7UQlc9yl5EduHfAARJM+Cgg== John, In today's meeting I was not able to express clearly a question I was asking about a part of the BMM/SBVR models. I have drawn a sketch that will hopefully make clearer the clarification I was seeking. View-A reflects what we agreed today as our working base (for the segmentation of the concept formerly known as Directive in your SBVR writeups). It shows the relabeled box 'element of governance'. It also shows the re-signified unary fact type, formerly "is actionable", now 'is directly enforceable'. You stated that this characteristic is needed to allow operable business rules (which are enforceable directly) to be distinguished from business policy (which is not directly enforceable). My question is reflected in View-B. Is not this view sufficient to support making that distinction by virtue of every operative business rule requiring an associated level of enforcement (and the fact that no business policy can have a level of enforcement)? In other words, instead of saying (for o.br) that it is an "element of governance that is directly enforceable" we can (already) say that it is an "element of governance that has some level of enforcement". What am I missing? ~ Keri file: Issue9447-ModelViewsA-B.jpg Issue9447-ModelViewsA-B.jpg User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Sun, 13 Aug 2006 06:29:53 -0700 Subject: Re: issue 9477 -- actionable From: John and Keri To: SBVR-FTF Thread-Topic: issue 9477 -- actionable Thread-Index: Aca+3I8gza1ToCrPEduHfAARJM+Cgg== Per Friday.s telcon, the attached reflects what was agreed Friday (Aug. 11) as a common view of these .guidance. elements in a harmonized SBVR and BMM. Please let me know if you spot anything that I captured incorrectly, or that has problems. regards, ~ Keri PS - The A.2.3.3 material still needs to be changed per the wording changes agreed in the Aug. 2 telcon. I don.t have notes for those changes. Don, I believe you took down those notes; please send them to me and I.ll incorporate them into the next (hopefully .final.) draft. Issue9477-C-applied.doc Subject: RE: issue 9477 -- actionable Date: Mon, 14 Aug 2006 12:02:14 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 9477 -- actionable Thread-Index: Aca+3I8gza1ToCrPEduHfAARJM+CggA9bCoQ From: "Baisley, Donald E" To: "John and Keri" , "SBVR-FTF" X-OriginalArrivalTime: 14 Aug 2006 19:02:15.0045 (UTC) FILETIME=[27ECF350:01C6BFD4] Keri, Notes on the A.2.3 material: 1. In the second sentence of the second paragraph of A.2.3.3, change .If. to .Because. so that the sentence starts out .Because an operative business rule is practicable, ... 2. The sentence at the end of the first paragraph of A.2.3.4 refers to .the obligation example given above.. But that example is too far above for the reference to make sense. Best regards, Don -------------------------------------------------------------------------------- From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] Sent: Sunday, August 13, 2006 6:30 AM To: SBVR-FTF Subject: Re: issue 9477 -- actionable Per Friday.s telcon, the attached reflects what was agreed Friday (Aug. 11) as a common view of these .guidance. elements in a harmonized SBVR and BMM. Please let me know if you spot anything that I captured incorrectly, or that has problems. regards, ~ Keri PS - The A.2.3.3 material still needs to be changed per the wording changes agreed in the Aug. 2 telcon. I don.t have notes for those changes. Don, I believe you took down those notes; please send them to me and I.ll incorporate them into the next (hopefully .final.) draft. Date: Thu, 17 Aug 2006 17:38:54 +0100 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: SBVR-FTF Subject: [SBVR] Issue 9477 - impact on BMM Hello all, Attached is the first draft of an issue I propose to raise for BMM. It's a consequence of the resolution of issue 9477 in SBVR, to maintain consistency between BMM and SBVR. SBVR 9477 is almost ready for voting. I am providing this draft to SBVR FTF members so that they can assure themselves that the BMM and SBVR specifications can be kept consistent. After the 9477 resolution has been voted into SBVR, I will raise this issue formally with the BMM FTF. I have also proposed changes to two concepts in SBVR. They are shown on the marked-up copy of Keri's "Applied" document for 9477. Regards, John Issue9477-C-applied JH.doc SBVR_9477_BMM.doc 12 Business Rules _____________________________________________________ Vocabulary for Describing Business Rules Language: English Included Vocabulary: Vocabulary for Describing Business Vocabulary _____________________________________________________ 12.1 Categories of Guidance Figure 12.1 ___________________________________________________________________ This diagram is not normative abstract syntax for SBVR, but is for illustration only. ___________________________________________________________________ 12.1.1 Guidance body of shared guidance Definition: all of the elements of guidance within a body of shared meanings body of shared meanings includes body of shared guidance Synonymous Form: body of shared guidance is included in body of shared meanings element of guidance General Concept: proposition Definition: means that guides, defines or constrains some aspect of an enterprise Note: This sense of 'means' (as in 'ends and means', rather than 'is meant as') arises from the Business Motivation Model [BMM]. Note: The formulation of an element of guidance is under an enterprise.s control by a party authorized to manage, control or regulate the enterprise, by selection from alternatives in response to a combination of assessments. body of shared guidance includes element of guidance Synonymous Form: element of guidance is included in body of shared guidance element of guidance is practicable Concept Type: characteristic Definition: the element of guidance is sufficiently detailed and precise that a person who knows the element of guidance can apply it effectively and consistently in relevant circumstances to know what behavior is acceptable or not, or how something is decided or calculated Dictionary Basis: able to be done or put into practice successfully; able to be used, useful [ODE] Note: The sense intended is: "It's actually something you can put to use or apply." Note: The behavior, decision or calculation can be that person's own. Note: Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. Note: A practicable business rule is also always free of any indefinite reference to people (e.g., "you", "me"), places (e.g., "here"), and time (e.g., "now"). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to "tell" time), and (b) external clarification. element of governance Definition:business policy or operative business rule Definition: element of guidance that is concerned with controlling, influencing or regulating the actions of an enterprise and the people in it Dictionary Basis: conduct the policy, actions, and affairs of (a state, organization, or people) with authority: control, influence, or regulate (a person, action, or course of events) [ODE, .govern.] General Concept: element of guidance element of governance is directly enforceable Definition:the element of governance is able to be done or acted upon; is practicable Definition: violations of the element of governance can be detected without the need for additional interpretation Concept Type: characteristic Note: 'Directly enforceable' means that a person who knows about the element of governance could observe a relevant situation business activity (including his or her own behavior) and decide directly whether or not the business was complying with the element of guidancegovernance. Necessity: Each element of governance that is directly enforceable is practicable. Necessity: An element of governance that is not directly enforceable is not practicable. business policy Definition: element of guidance that is not directly enforceable whose purpose is to guide an enterprise General Concept: element of guidance, element of governance Note: Compared to a Business Rule, a Business Policy tends to be: - less structured - less discrete or not atomic - less carefully expressed in terms of standard vocabulary - not directly enforceable. Dictionary Basis: definite course or method of action selected (as by a government, institution, group, or individual) from among alternatives and in the light of given conditions to guide and usually determine present and future decisions [MWUD "Policy" 5a] Necessity: No business policy is a business rule. Example: The policy expressed as "A prisoner is considered to be on a hunger strike after missing several meals in a row." proposition is based on fact type Definition: the proposition is formulated using the fact type Example: The EU-Rent business rule that is expressed as "It is obligatory that each rental specifies a car group." (or, in RuleSpeak, "A rental must have a car group.") is based on the EU-Rent fact type 'rental specifies car group'. 12.1.2 Rules rule Definition: proposition that introduces an obligation or a necessity Dictionary Basis: one of a set of explicit or understood regulations or principles governing conduct or procedure within a particular area of activity. a law or principle that operates within a particular sphere of knowledge, describing or prescribing what is possible or allowable. [ODE] [per proposed resolution to Issue 9579] business rule Definition: rule that is under business jurisdiction General Concept: rule, element of guidance business rule is derived from business policy Synonymous Form: business policy is basis for business rule structural rule Definition: rule that is intended as a definitional criterion Necessity: Each structural rule is a proposition that another proposition is a necessity. Synonym: definitional rule definitional rule See: structural rule structural business rule Definition: structural rule that is a business rule Synonym: definitional business rule Necessity: Each structural business rule is practicable. definitional business rule See: structural business rule operative business rule Definition: business rule that is intended to produce an appropriate or designed effect General Concept: business rule, element of governance Definition: business rule that covers conduct, action, practice, or procedure within a particular activity or sphere Definition: business rule that there is an obligation concerning conduct, action, practice or procedure Dictionary Basis: a prescribed, suggested, or self-imposed guide for conduct or action : a regulation or principle [.] [MWU (1a) 'rule'] Dictionary Basis: a prescribed guide for conduct or action [MWCD 'rule'] Necessity: Each operative business rule is a proposition that another proposition is an obligation. Necessity: No operative business rule is a structural business rule. Necessity: Each operative business rule is directly enforceable. Synonym: behavioral business rule behavioral business rule See: operative business rule 12.1.3 Enforcement level of enforcement Definition: something that represents a position in a graded or ordered scale of values that specifies the severity of action imposed in order to put or keep an operative business rule in force Dictionary Basis: a position on a real or imaginary scale of amount, quantity, extent, or quality [NODE 'level'] Dictionary Basis: compel observance of or compliance with [NODE 'enforcement'] Example: An example set of levels of enforcement, based on [BRG-ODP] Enforcement Level: strict Description: strictly enforced (If you violate the rule, you cannot escape the penalty.) Enforcement Level: deferred Description: deferred enforcement (Strictly enforced, but enforcement may be delayed . e.g., waiting for resource with required skills.) Enforcement Level: pre-authorized Description: pre-authorized override (Enforced, but exceptions allowed, with prior approval for actors with before-the-fact override authorization.) Enforcement Level: post-justified Description: post-justified override (If not approved after the fact, you may be subject to sanction or other consequences.) Enforcement Level: override Description: override with explanation (Comment must be provided when the violation occurs.) Enforcement Level: guideline Description: guideline (suggested, but not enforced.) operative business rule has level of enforcement 12.1.4 Admonitions and Affirmations admonition Definition: element of guidance that is practicable and that is a proposition that there is not an obligation or necessity where, by custom or practice, one might be assumed Note: The purpose of an admonition is to preempt application of "rules" that might be assumed by some members of a semantic community, but are not actually rules admitted by the community. Often, the reason for this assumption in a business is that other, similar, businesses have such rules. Typically, the reason for an explicit admonition is that people in the business have mistakenly applied the non-existent "rule" in the past. Example: (In a bank) There is no rule that a person must be over some given age in order open a savings account: "There is no minimum age for opening a savings account". Example: (In EU-Rent) There is no rule that a rented car can be dropped off only at the return branch specified in the rental agreement: "At the end of a rental, a rental car can be dropped off at any EU-Rent branch". There is a related rule that if the drop-off branch is not the specified return branch, the rental will incur a penalty charge, but the importance of this admonition is that EU-Rent wants its cars back, even if they are in the wrong places. It does not want a branch to refuse to accept a car on the grounds that it is not the specified return branch. Necessity: No rule is an admonition. Necessity: No business policy is an admonition. Necessity: No business rule is an admonition. affirmation Definition: element of guidance that is practicable and that is a proposition that there is a permissibility or possibility where, by custom or practice, one might not be assumed Example: (In a bank) "It is possible that an account balance is negative". Example: (In EU-Rent) "A rental car may be dropped off at any EU-Rent branch, even one that is not its scheduled drop-off branch". Necessity: Each affirmation is a proposition that another proposition is a possibility or a permissibility. Necessity: No rule is an affirmation. Necessity: No admonition is an affirmation. Necessity: No business policy is an affirmation. Necessity: No business rule is an affirmation. On PDF pages 178-179 Note: This material still needs to reflect the detail of the wording changes agreed in the Aug. 2 telcon. A.2.3.3 What 'Practicable' Means All business rules (and affirmations and admonitions as well) need to be practicable. Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. If an operative business rule is practicable, a person who knows about it can decide directly whether it is being followed when that person observes relevant behavior. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. If a structural rule is practicable, a person who knows about it can also decide directly whether it is being followed when that person observes some relevant outcome from a decision or calculation. A practicable business rule is also always free of any indefinite reference to people (e.g., "you", "me"), places (e.g., "here"), and time (e.g., "now"). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to "tell" time), and (b) external clarification. All these criteria assume that the person understands the business concepts that underlie the business rule. A practicable business rule always imparts ready-to-apply knowledge of the kinds above 'on top' of such concepts. An important best practice for business rules, following naturally from this, is that the underlying business vocabulary/ies must be well developed and well managed. Specifically, each business concept should: o Be individually well defined. o Fit logically into the overall structure of concepts. o Made available to the person in appropriate manner. In addition, each business rule should be directly expressible in the given business vocabulary/ies. These best practices point toward the essential role of business vocabularies in supporting business rules . indeed, the bulk of SBVR is devoted to that area. A.2.3.4 Business Rules that Cannot Be Automated Just because business rules are practicable, this does not imply they are always automatable. Many business rules, especially operative business rules, are not automatable in IT systems. For instance, consider the obligation example given above. This distinction is not important within SBVR, which focuses on rules only from the business perspective, regardless of whether the rules could be automated. However, it is obviously important in defining a transformation from business model to PIM. In particular, non-automatable business rules need to be implemented as user activity, supported by procedure manuals or rulebooks. BMM Issue - consequential from SBVR issue 9477 Context SBVR Issue 9477 is almost ready for voting by the SBVR FTF. The changes to SBVR affect business rule (adopted from SBVR by BMM) and business policy (adopted from BMM by SBVR). This note is a draft of the consequential BMM issue and proposed resolution. It is provided so that SBVR FTF members can see the impact on BMM, and assure themselves that SBVR and BMM will remain consistent. It will be formally raised as a BMM issue when the changes to SBVR have been voted in. BMM Issue In response to some SBVR FTF issues, several changes have been made to SBVR that affect business rule (adopted from SBVR by BMM) and business policy (adopted from BMM by SBVR). BMM needs to be updated in order to remain consistent with SBVR. Summary of SBVR changes The resolution of SBVR Issue 9477 caused the verb concept (unary fact type) directive is actionable to be replaced by two verb concepts with narrower definitions: · element of guidance is practicable: this is concerned with ensuring that business rules are sufficiently well-defined and precise that they can be put directly into practice. · element of governance is directly enforceable: this is concerned with ensuring that violations of operative business rules can be detected and corrected. This separation of concerns is relevant to BMM. If desired results for an enterprise are not being achieved, there could be two causes related to business rules: 1. The enterprise does not have the right business rules. 2. The enterprise and, particularly, the people in the enterprise are not applying the rules correctly. Before challenging whether the business rules are the right ones, it would be important to establish that the rules were being applied as they were intended to be. To establish this, the rules must be enforceable. There were also some minor structural changes in SBVR: · the extension of element of guidance has been redefined to incorporate what was formerly directive and to exclude rule and structural rule · element of governance has been introduced as a category of element of guidance and a more general concept for business policy and operative business rule They changes are shown in fragments of SBVR in the diagrams on the following pages. Fragment of SBVR as in current specification (dtc/06-03-02.pdf) Fragment of SBVR after resolution of Issue 9477 Fragment of SVBR after resolution of SBVR issue 9477 that is relevant to BMM Proposed Resolution for BMM 1) Adopt from SBVR: element of guidance, element of governance, operative business rule, structural business rule [business rule has already been adopted]. 2) Replace directive with element of guidance and element of governance. 3) Assign the associations in which directive current participates so that: · those concerned with governance are assigned to element of governance · all others are assigned to element of guidance 4) Add operative business rule as a category of element of governance that is delimited from business policy The changes are illustrated on the diagrams on the following pages. 5) Add the sentence from the current definition of directive .It is intended to assert business structure or to control or influence the behavior of the enterprise. to the adopted definition of element of guidance. Omit the first note (about the .sense of means.) from the adopted definition. 6) Define element of governance: is an element of guidance that is concerned with controlling, influencing or regulating the actions of an enterprise and the people in it Dictionary basis: "conduct the policy, actions, and affairs of (a state, organization, or people) with authority: control, influence, or regulate (a person, action, or course of events)" [ODE, .govern.] 7) Replace .not actionable. in business policy with .not directly enforceable. 8) Add a definition of .element of governance is directly enforceable. (which doesn.t appear explicitly on the UML class diagram for BMM), plus supporting note: violations of the element of governance can be detected without the need for additional interpretation Note: .Directly enforceable. means that a person who understands an Element of Governance could observe relevant business activity (including his or her own behavior) and decide directly whether or not the business was complying with that Element of Governance. In contrast to Operative Business Rules, Business Policies are not directly enforceable in that sense. 9) Add some explanation of Directly Enforceable If an enterprise.s Desired Results are not being achieved, there are many possible causes. For example, the Courses of Action may not be the right ones to deliver the Desired Results, the Business Processes that realize the Courses of Action may not be appropriately designed, etc. Two possible causes rooted in governance are: · The enterprise may not have the right Elements of Governance (part of .doing the right things.) · The people in the enterprise may not be applying the Elements of Governance as intended (part of .doing things right.) Before challenging whether the Elements of Governance are right, it is important to establish whether they are being applied as intended. This has two parts. First, the Elements of Governance must be enforceable; then the enforcement (detection of violation, remedial action and - if appropriate - sanctions against the responsible organization roles) must be done in the operational business. A Business Policy is not directly enforceable. To be made operational, it requires more specific Operative Business Rules to be derived from it. For example, in EU-Rent: .rental cars must not be exported. is not sufficiently precise to be directly enforced. It is a Business Policy, and needs Operative Business Rules through which it can be enforced. For example: · Each rental car must be registered in the country of the local area to which it is assigned after purchase · The country of registration of a rental car must not be changed · If a car is at a location outside its country of registration, it may be assigned only to a rental with return location in its country of registration · If a rental car is at a location outside its country of registration for more than five days, it must be returned to its country of registration. In this case the Operative Business Rules serve not only to enable enforceability. They also clarify EU-Rent.s intent. This Business Policy is not just about the legal aspect of export (transfer of country of registration, etc). EU-Rent also wants to ensure that, if a car is dropped off .out of country. at the end of a rental, it should not be treated as if it had been exported - the drop-off location can use it only in very restricted ways. Fragment of BMM structure as in FAS, showing Directive and its associations Equivalent fragment after proposed changes User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 17 Aug 2006 11:24:07 -0700 Subject: Re: [SBVR] Issue 9477 - impact on BMM From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR] Issue 9477 - impact on BMM Thread-Index: AcbCKlNikgyBdy4dEdu3twARJM+Cgg== Thanks, John. FTFers, Please send me any additional material (or feedback to John's modifications) by end of day today. I will then incorporate the changes I have received (including the two additional change items discussed yesterday) and re-issue the material for 9477. Regards, ~ Keri On 8/17/06 9:38 AM, "John Hall" wrote: > Hello all, > > Attached is the first draft of an issue I propose to raise for BMM. > It's a consequence of the resolution of issue 9477 in SBVR, to maintain > consistency between BMM and SBVR. > > SBVR 9477 is almost ready for voting. I am providing this draft to SBVR > FTF members so that they can assure themselves that the BMM and SBVR > specifications can be kept consistent. After the 9477 resolution has > been voted into SBVR, I will raise this issue formally with the BMM FTF. > > I have also proposed changes to two concepts in SBVR. They are shown on > the marked-up copy of Keri's "Applied" document for 9477. > > Regards, > > John > User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Mon, 14 Aug 2006 20:55:05 -0700 Subject: Re: issue 9477 -- clarification on ability to discriminate From: John and Keri To: John Hall , SBVR-FTF Thread-Topic: issue 9477 -- clarification on ability to discriminate Thread-Index: AcbAHpeA1dTF3iwREduANQARJM+Cgg== Do we want to include this (or a variation of it) as a new section in Annex A . say, following A.2.3.4? regards, ~ Keri On 8/14/06 2:59 PM, "John Hall" wrote: Keri, You suggested your View B and the following definitions: element of governance: business policy or operative business rule operative business rule: element of governance that has some level of enforcement (or, from the diagram, element of governance that must have at least one level of enforcement) business policy: element of governance that has no level of enforcement (or, from the diagram, element of governance that cannot have any level of enforcement) This would be good as a fragment of the model for an SBVR support tool. A developer would know how to build the tool. A user would be able to store the SBVR model for his/her enterprise in the tool. To store elements of governance, the user would have different input options for business policies and operative business rules, and after inputting an operative business rule would be required to connect a level of enforcement to it. This would work only if, before inputting them, the user knew which elements of governance were business policies and which were operative business rules. The purpose of business-oriented definitions is to enable modelers to make this recognition. There are two parts to having business rules that guide the business as the stakeholders want it to run. One is having the right rules. This is part of .doing the right things., and business rules being practicable is part of it - the elements of guidance have to be sufficiently precise and detailed that they can be put into practice. Then,if the business isn.t running as the stakeholders wanted, the business rules ought to be questioned. Are they the right rules? But before questioning whether the business rules were the right ones, you.d want to ensure that people in the business were doing what they are supposed to. Perhaps the rules are the right ones, but people in the business aren.t applying them correctly. This is part of .doing things right., and operative business rules being enforceable is part of it. To be enforceable, an operative business rule has to be defined in such a way that violations can be detected. The enforcement regime can then detect violation, take corrective action and (if appropriate) impose penalties on the violators. Elements of governance direct what people do in the business, and they need to be enforceable. Being directly enforceable is what delimits business policy from operative business rule. The importance of this is that when people modeling a business encounter (or need to define) elements of governance in the real world, they need to think about two things. First, is the element of governance directly enforceable - i.e. is it possible to observe what people are doing, and recognize whether they are complying or not, without needing further amplification or explanation? If it is not, then the element of governance is a business policy and the modelers haven.t yet finished the model. They also need to develop operative business rules that are derived from the business policy and are directly enforceable. For example, the EU-Rent element of governance .rental cars must not be exported. is not sufficiently precise to be enforced. It is a business policy, and needs operative business rules through which it can be enforced. For example: Each rental car must be registered in the country of the local area to which it is assigned after purchase The country of registration of a rental car must not be changed If a car is at a location outside its country of registration, it may be assigned only to a rental with return location in its country of registration If a rental car is at a location outside its country or registration for more than five days, it must be returned to its country of registration. Second, if the element of governance is directly enforceable, it ought to be derived from a business policy. If it is not, the modelers ought to be aware that this is so (and might choose to question whether the rule is appropriate). This is not about methodology. It is fundamental to getting the business rules that will have the effects required by the stakeholders. People who will use SBVR successfully need to know about it. I think it needs to be stated in the definitions and their supporting notes and examples. A definition such as .operative business rule: element of governance that has some level of enforcement. supports only the last step in the process - how to record it when you know what it is. Regards, John John and Keri wrote: John, In today's meeting I was not able to express clearly a question I was asking about a part of the BMM/SBVR models. I have drawn a sketch that will hopefully make clearer the clarification I was seeking. View-A reflects what we agreed today as our working base (for the segmentation of the concept formerly known as Directive in your SBVR writeups). It shows the relabeled box 'element of governance'. It also shows the re-signified unary fact type, formerly "is actionable", now 'is directly enforceable'. You stated that this characteristic is needed to allow operable business rules (which are enforceable directly) to be distinguished from business policy (which is not directly enforceable). My question is reflected in View-B. Is not this view sufficient to support making that distinction by virtue of every operative business rule requiring an associated level of enforcement (and the fact that no business policy can have a level of enforcement)? In other words, instead of saying (for o.br) that it is an "element of governance that is directly enforceable" we can (already) say that it is an "element of governance that has some level of enforcement". What am I missing? ~ Keri file: Issue9447-ModelViewsA-B.jpg Date: Mon, 14 Aug 2006 22:59:24 +0100 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: John and Keri Cc: SBVR-FTF Subject: Re: issue 9477 -- clarification on ability to discriminate Keri, You suggested your View B and the following definitions: element of governance: business policy or operative business rule operative business rule: element of governance that has some level of enforcement (or, from the diagram, element of governance that must have at least one level of enforcement) business policy: element of governance that has no level of enforcement (or, from the diagram, element of governance that cannot have any level of enforcement) This would be good as a fragment of the model for an SBVR support tool. A developer would know how to build the tool. A user would be able to store the SBVR model for his/her enterprise in the tool. To store elements of governance, the user would have different input options for business policies and operative business rules, and after inputting an operative business rule would be required to connect a level of enforcement to it. This would work only if, before inputting them, the user knew which elements of governance were business policies and which were operative business rules. The purpose of business-oriented definitions is to enable modelers to make this recognition. There are two parts to having business rules that guide the business as the stakeholders want it to run. One is having the right rules. This is part of .doing the right things., and business rules being practicable is part of it - the elements of guidance have to be sufficiently precise and detailed that they can be put into practice. Then,if the business isn.t running as the stakeholders wanted, the business rules ought to be questioned. Are they the right rules? But before questioning whether the business rules were the right ones, you.d want to ensure that people in the business were doing what they are supposed to. Perhaps the rules are the right ones, but people in the business aren.t applying them correctly. This is part of .doing things right., and operative business rules being enforceable is part of it. To be enforceable, an operative business rule has to be defined in such a way that violations can be detected. The enforcement regime can then detect violation, take corrective action and (if appropriate) impose penalties on the violators. Elements of governance direct what people do in the business, and they need to be enforceable. Being directly enforceable is what delimits business policy from operative business rule. The importance of this is that when people modeling a business encounter (or need to define) elements of governance in the real world, they need to think about two things. First, is the element of governance directly enforceable - i.e. is it possible to observe what people are doing, and recognize whether they are complying or not, without needing further amplification or explanation? If it is not, then the element of governance is a business policy and the modelers haven.t yet finished the model. They also need to develop operative business rules that are derived from the business policy and are directly enforceable. For example, the EU-Rent element of governance .rental cars must not be exported. is not sufficiently precise to be enforced. It is a business policy, and needs operative business rules through which it can be enforced. For example: Each rental car must be registered in the country of the local area to which it is assigned after purchase The country of registration of a rental car must not be changed If a car is at a location outside its country of registration, it may be assigned only to a rental with return location in its country of registration If a rental car is at a location outside its country or registration for more than five days, it must be returned to its country of registration. Second, if the element of governance is directly enforceable, it ought to be derived from a business policy. If it is not, the modelers ought to be aware that this is so (and might choose to question whether the rule is appropriate). This is not about methodology. It is fundamental to getting the business rules that will have the effects required by the stakeholders. People who will use SBVR successfully need to know about it. I think it needs to be stated in the definitions and their supporting notes and examples. A definition such as .operative business rule: element of governance that has some level of enforcement. supports only the last step in the process - how to record it when you know what it is. Regards, John John and Keri wrote: John, In today's meeting I was not able to express clearly a question I was asking about a part of the BMM/SBVR models. I have drawn a sketch that will hopefully make clearer the clarification I was seeking. View-A reflects what we agreed today as our working base (for the segmentation of the concept formerly known as Directive in your SBVR writeups). It shows the relabeled box 'element of governance'. It also shows the re-signified unary fact type, formerly "is actionable", now 'is directly enforceable'. You stated that this characteristic is needed to allow operable business rules (which are enforceable directly) to be distinguished from business policy (which is not directly enforceable). My question is reflected in View-B. Is not this view sufficient to support making that distinction by virtue of every operative business rule requiring an associated level of enforcement (and the fact that no business policy can have a level of enforcement)? In other words, instead of saying (for o.br) that it is an "element of governance that is directly enforceable" we can (already) say that it is an "element of governance that has some level of enforcement". What am I missing? ~ Keri file: Issue9447-ModelViewsA-B.jpg X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 15 Aug 2006 16:28:44 -0500 To: john.hall@modelsys.com, John and Keri From: "Ronald G. Ross" Subject: Re: issue 9477 -- clarification on ability to discriminate Cc: SBVR-FTF At 04:59 PM 8/14/2006, John Hall wrote: Keri, Second, if the element of governance is directly enforceable, it ought to be derived from a business policy. If it is not, the modelers ought to be aware that this is so (and might choose to question whether the rule is appropriate). This is not about methodology. It is fundamental to getting the business rules that will have the effects required by the stakeholders. People who will use SBVR successfully need to know about it. I think it needs to be stated in the definitions and their supporting notes and examples. Observation: I can certainly visualize some tools and/or users focusing on only stuff that's practicable, considering other guidance things outside scope. We would certainly not want to do anything in SBVR to discourage or impede such usage. Ron A definition such as .operative business rule: element of governance that has some level of enforcement. supports only the last step in the process - how to record it when you know what it is. Regards, John Date: Thu, 17 Aug 2006 17:38:54 +0100 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: SBVR-FTF Subject: [SBVR] Issue 9477 - impact on BMM Hello all, Attached is the first draft of an issue I propose to raise for BMM. It's a consequence of the resolution of issue 9477 in SBVR, to maintain consistency between BMM and SBVR. SBVR 9477 is almost ready for voting. I am providing this draft to SBVR FTF members so that they can assure themselves that the BMM and SBVR specifications can be kept consistent. After the 9477 resolution has been voted into SBVR, I will raise this issue formally with the BMM FTF. I have also proposed changes to two concepts in SBVR. They are shown on the marked-up copy of Keri's "Applied" document for 9477. Regards, John Issue9477-C-applied JH.doc SBVR_9477_BMM.doc User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 17 Aug 2006 11:24:07 -0700 Subject: Re: [SBVR] Issue 9477 - impact on BMM From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR] Issue 9477 - impact on BMM Thread-Index: AcbCKlNikgyBdy4dEdu3twARJM+Cgg== Thanks, John. FTFers, Please send me any additional material (or feedback to John's modifications) by end of day today. I will then incorporate the changes I have received (including the two additional change items discussed yesterday) and re-issue the material for 9477. Regards, ~ Keri On 8/17/06 9:38 AM, "John Hall" wrote: > Hello all, > > Attached is the first draft of an issue I propose to raise for BMM. > It's a consequence of the resolution of issue 9477 in SBVR, to maintain > consistency between BMM and SBVR. > > SBVR 9477 is almost ready for voting. I am providing this draft to SBVR > FTF members so that they can assure themselves that the BMM and SBVR > specifications can be kept consistent. After the 9477 resolution has > been voted into SBVR, I will raise this issue formally with the BMM FTF. > > I have also proposed changes to two concepts in SBVR. They are shown on > the marked-up copy of Keri's "Applied" document for 9477. > > Regards, > > John > Reply-To: From: "Donald Chapin" To: "'SBVR-FTF'" Subject: RE: [SBVR] Issue 9477 - impact on BMM Date: Mon, 21 Aug 2006 04:13:39 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbCKlNikgyBdy4dEdu3twARJM+CggCpPNzg Keri, Could you post the revised Issue 9477 Resolution so that everyone can satisfy themselves that the editing instructions in it represent the compromise solution that everyone agreed to in the Friday, August 11th, phone meeting? Many Thanks, Donald > -----Original Message----- > From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] > Sent: 17 August 2006 19:24 > To: SBVR-FTF > Subject: Re: [SBVR] Issue 9477 - impact on BMM > > Thanks, John. > > FTFers, Please send me any additional material (or feedback to John's > modifications) by end of day today. I will then incorporate the changes I > have received (including the two additional change items discussed > yesterday) and re-issue the material for 9477. > > Regards, > ~ Keri > > On 8/17/06 9:38 AM, "John Hall" wrote: > > > Hello all, > > > > Attached is the first draft of an issue I propose to raise for BMM. > > It's a consequence of the resolution of issue 9477 in SBVR, to maintain > > consistency between BMM and SBVR. > > > > SBVR 9477 is almost ready for voting. I am providing this draft to SBVR > > FTF members so that they can assure themselves that the BMM and SBVR > > specifications can be kept consistent. After the 9477 resolution has > > been voted into SBVR, I will raise this issue formally with the BMM FTF. > > > > I have also proposed changes to two concepts in SBVR. They are shown on > > the marked-up copy of Keri's "Applied" document for 9477. > > > > Regards, > > > > John > > > Date: Tue, 22 Aug 2006 18:18:51 +0100 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: John and Keri Cc: SBVR-FTF Subject: Re: [SBVR] Issue 9477 - updated 'applied' document Keri, I thought that you had asked for all input to be sent to you by end of August 17. If you are still accepting input, I would like to ask for a different example for .business policy.. We have several in BMM. The example used in the draft, "a prisoner is considered to be on a hunger strike after missing several meals in a row", was discussed in London. At least 3 participants (out of 7) thought it was simply a local adaptation of the dictionary definition of .hunger strike. (.a prolonged refusal to eat, carried out as a protest by a prisoner. ODE), rather than a business policy. My view of business policies is that they are generally bigger and broader than definitions. In this context, for example, policy options might be: let the prisoner die; force feed when a hunger strike is recognized (by meeting the local definition); deliver intravenous nutrition when the prisoner becomes too weak to eat autonomously. Regards, John John and Keri wrote: On 8/20/06 8:13 PM, "Donald Chapin" wrote: Keri, Could you post the revised Issue 9477 Resolution so that everyone can satisfy themselves that the editing instructions in it represent the compromise solution that everyone agreed to in the Friday, August 11th, phone meeting? Donald, To clarify -- I agreed to post an updated "applied" document, using the input John Hall sent (Aug. 17), as well as input from others. That material will be issued in time for the next round of discussion (i.e., the Aug. 30 meeting). Once there is agreement on the net changes under this Issue (hopefully, out of the Aug. 30 meeting), I will prepare the Edit Instructions, for review/approval. regards, Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 22 Aug 2006 07:59:02 -0700 Subject: Re: [SBVR] Issue 9477 - updated 'applied' document From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR] Issue 9477 - updated 'applied' document Thread-Index: AcbCKlNikgyBdy4dEdu3twARJM+CggCpPNzgAEsOkWw= On 8/20/06 8:13 PM, "Donald Chapin" wrote: > Keri, > > Could you post the revised Issue 9477 Resolution so that everyone can > satisfy themselves that the editing instructions in it represent the > compromise solution that everyone agreed to in the Friday, August 11th, > phone meeting? Donald, To clarify -- I agreed to post an updated "applied" document, using the input John Hall sent (Aug. 17), as well as input from others. That material will be issued in time for the next round of discussion (i.e., the Aug. 30 meeting). Once there is agreement on the net changes under this Issue (hopefully, out of the Aug. 30 meeting), I will prepare the Edit Instructions, for review/approval. regards, Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 22 Aug 2006 11:49:54 -0700 Subject: Re: [SBVR] Issue 9477 - updated 'applied' document From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR] Issue 9477 - updated 'applied' document Thread-Index: AcbGG8GIAAZORDIPEdufQQARJM+Cgg== X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k7MIoC8V009273 On 8/22/06 10:18 AM, "John Hall" wrote: > Keri, > > I thought that you had asked for all input to be sent to you by end of August > 17. I had. And then our DSL service went out for 24 hrs.+ ... (don't ask!) > If you are still accepting input, ... Turning our modest, local crisis into an opportunity, my window to work on this material has shifted. Accordingly, I'll take input (from you & anyone else who has input to 9477) through end of day Saturday (Aug. 26). > ... I would like to ask for a different > example for ³business policy². We have several in BMM. ... If you have examples of specific wording additions you'd like, please provide it. Thanks! ~ Keri DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-MimeOLE:In-reply-to:Thread-Index; b=QdeNGF8pCgkxEh77MM86+vgChvhKdJGcAE2iuz1SP/W05G6RhXYHrARQF5SQShTdiwmDHzrHF58yItmh9Ee+c3XNtHuW6HrXX+R3otnJEuxGFLy2+yQKIfqGSehIYkOIqL6twj2vKCF6PS3FTedVzAjwqRq1H05IVKCD+oTv1mk= ; Reply-To: From: "Donald Chapin" To: "'SBVR-FTF'" Subject: RE: [SBVR] Issue 9477 - updated 'applied' document Date: Wed, 23 Aug 2006 12:50:47 +0800 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbCKlNikgyBdy4dEdu3twARJM+CggCpPNzgAEsOkWwAFcWXAAAEXx5QAAJuSWA= Keri, I'm still hoping that we can put the Issue Resolution for the four packaged Issues to a vote before the end of the week of Aug. 28 - Sept. 1. I have been told by the OMG that we have a little leeway on getting the SBVR FTF Report by Monday, Sept 4th. It will be much better with the Architecture Board not to have to defer these key Issues. It would also be better for progress and the morale of the SBVR FTF team to have these four Issues behind us. In any case, we either have to vote on a Resolution or Deferral of these four Issues before the SBVR FTF Report can be completed. If we can agree on an Issue Resolution, the page numbers will not need to be changed. Donald > -----Original Message----- > From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] > Sent: 23 August 2006 11:28 > To: Donald R. Chapin; SBVR-FTF > Subject: Re: [SBVR] Issue 9477 - updated 'applied' document > > On 8/22/06 6:30 PM, "Donald Chapin" wrote: > > > ... editing instructions would be done only after we agreed to the > 'applied' > > document in the Aug. 30th meeting. > > Donald, > > This raises an "interesting" question. If I understand the plan, there > will > be a new Convenience Document. And if that is the case, won't all our > 'deferred' Resolution Edit Instructions need to be tweaked to reflect the > page/paragraph references of that newer version? > > Hmmm... > > ~ Keri > DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-MimeOLE:In-reply-to:Thread-Index; b=QdeNGF8pCgkxEh77MM86+vgChvhKdJGcAE2iuz1SP/W05G6RhXYHrARQF5SQShTdiwmDHzrHF58yItmh9Ee+c3XNtHuW6HrXX+R3otnJEuxGFLy2+yQKIfqGSehIYkOIqL6twj2vKCF6PS3FTedVzAjwqRq1H05IVKCD+oTv1mk= ; Reply-To: From: "Donald Chapin" To: "'SBVR-FTF'" Subject: RE: [SBVR] Issue 9477 - updated 'applied' document Date: Wed, 23 Aug 2006 12:50:47 +0800 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbCKlNikgyBdy4dEdu3twARJM+CggCpPNzgAEsOkWwAFcWXAAAEXx5QAAJuSWA= Keri, I'm still hoping that we can put the Issue Resolution for the four packaged Issues to a vote before the end of the week of Aug. 28 - Sept. 1. I have been told by the OMG that we have a little leeway on getting the SBVR FTF Report by Monday, Sept 4th. It will be much better with the Architecture Board not to have to defer these key Issues. It would also be better for progress and the morale of the SBVR FTF team to have these four Issues behind us. In any case, we either have to vote on a Resolution or Deferral of these four Issues before the SBVR FTF Report can be completed. If we can agree on an Issue Resolution, the page numbers will not need to be changed. Donald > -----Original Message----- > From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] > Sent: 23 August 2006 11:28 > To: Donald R. Chapin; SBVR-FTF > Subject: Re: [SBVR] Issue 9477 - updated 'applied' document > > On 8/22/06 6:30 PM, "Donald Chapin" wrote: > > > ... editing instructions would be done only after we agreed to the > 'applied' > > document in the Aug. 30th meeting. > > Donald, > > This raises an "interesting" question. If I understand the plan, there > will > be a new Convenience Document. And if that is the case, won't all our > 'deferred' Resolution Edit Instructions need to be tweaked to reflect the > page/paragraph references of that newer version? > > Hmmm... > > ~ Keri > User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 23 Aug 2006 05:40:48 -0700 Subject: Re: [SBVR] Issue 9477 and 9613 - as package elements From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR] Issue 9477 and 9613 - as package elements Thread-Index: AcbCKlNikgyBdy4dEdu3twARJM+CggCpPNzgAEsOkWwAFcWXAAAEXx5QAAJuSWAAEOO2sQ== On 8/22/06 9:50 PM, "Donald Chapin" wrote: > Keri, > > I'm still hoping that we can put the Issue Resolution for the four packaged > Issues to a vote before the end of the week of Aug. 28 - Sept. 1. Hmmm... From the perspective of 9613, that seems awfully optimistic. We are still working on coming to a common perspective on the terminology (the first 'component') and haven't even begun to review/grasp the architectural features of the second (the 'rule-less' SBVR component). > I have been told by the OMG that we have a little leeway on getting the SBVR > FTF Report by Monday, Sept 4th. > > It will be much better with the Architecture Board not to have to defer > these key Issues. It would also be better for progress and the morale of > the SBVR FTF team to have these four Issues behind us. But, of course, only with solid understanding and agreement. > In any case, we either have to vote on a Resolution or Deferral of these > four Issues before the SBVR FTF Report can be completed. > > If we can agree on an Issue Resolution, the page numbers will not need to be > changed. Thanks for confirming my understanding that the page numbers would need to be changed if deferred. ~ Keri DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-MimeOLE:In-reply-to:Thread-Index; b=v9PGD7ugx8IRWzUIr3EnL7Ng+sqgZe3t3e8R5tn8Qog2sMzBOoy7uWSiiOd1TGDIxLP632iDhcmWcVUY15RJd9Liojr42tduRshL/GZiIiGq/xK6ejFsuzLW6bo4v8lq5C+jCE+C8kXlkmvjfXcdoOsCFij3nTH2aDu5jyz0jAs= ; Reply-To: From: "Donald Chapin" To: "'John and Keri'" , "'SBVR-FTF'" Subject: RE: [SBVR] Issue 9477 - updated 'applied' document Date: Wed, 23 Aug 2006 09:30:41 +0800 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbCKlNikgyBdy4dEdu3twARJM+CggCpPNzgAEsOkWwAFcWXAA== Keri, You are correct that you agreed to supply an 'applied' document, and that editing instructions would be done only after we agreed to the 'applied' document in the Aug. 30th meeting. I had the picture of the 'applied' document in my mind, but incorrectly asked for the 'editing instructions'. I apologize that that mistake. It would be helpful to have the 'applied' document well before Aug.30th. Many Thanks, Donald > -----Original Message----- > From: John and Keri [mailto:JohnAndKeri@mywaikikicondo.com] > Sent: 22 August 2006 22:59 > To: SBVR-FTF > Subject: Re: [SBVR] Issue 9477 - updated 'applied' document > > On 8/20/06 8:13 PM, "Donald Chapin" wrote: > > Keri, > > > > Could you post the revised Issue 9477 Resolution so that everyone can > > satisfy themselves that the editing instructions in it represent the > > compromise solution that everyone agreed to in the Friday, August 11th, > > phone meeting? > > Donald, > > To clarify -- I agreed to post an updated "applied" document, using the > input John Hall sent (Aug. 17), as well as input from others. That > material > will be issued in time for the next round of discussion (i.e., the Aug. 30 > meeting). Once there is agreement on the net changes under this Issue > (hopefully, out of the Aug. 30 meeting), I will prepare the Edit > Instructions, for review/approval. > > regards, > Keri > User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 22 Aug 2006 20:27:36 -0700 Subject: Re: [SBVR] Issue 9477 - updated 'applied' document From: John and Keri To: "Donald R. Chapin" , SBVR-FTF Thread-Topic: [SBVR] Issue 9477 - updated 'applied' document Thread-Index: AcbCKlNikgyBdy4dEdu3twARJM+CggCpPNzgAEsOkWwAFcWXAAAEXx5Q On 8/22/06 6:30 PM, "Donald Chapin" wrote: > ... editing instructions would be done only after we agreed to the 'applied' > document in the Aug. 30th meeting. Donald, This raises an "interesting" question. If I understand the plan, there will be a new Convenience Document. And if that is the case, won't all our 'deferred' Resolution Edit Instructions need to be tweaked to reflect the page/paragraph references of that newer version? Hmmm... ~ Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 22 Aug 2006 20:49:09 -0700 Subject: Re: [SBVR] Issue 9477 - updated 'applied' document From: John and Keri To: "Donald R. Chapin" , SBVR-FTF Thread-Topic: [SBVR] Issue 9477 - updated 'applied' document Thread-Index: AcbCKlNikgyBdy4dEdu3twARJM+CggCpPNzgAEsOkWwAFcWXAAAFH8q8 On 8/22/06 6:30 PM, "Donald Chapin" wrote: > ... > It would be helpful to have the 'applied' document well before Aug.30th. In his note today, John Hall indicated that he has additional input/feedback. So I've given him (& others) through this Sat. (Aug. 26) to get any additional input to me. Since this issue only has a handful of updates let's hope that it should not take considerable time for our folks to digest the resulting "new look". In any case, yes, the material will be out prior to the Wed. meeting so that everyone can give it a careful look. regards, ~ Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Thu, 24 Aug 2006 07:57:20 -0700 Subject: Re: [SBVR] Issue 9477 - updated 'applied' document ("D") From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR] Issue 9477 - updated 'applied' document ("D") Thread-Index: AcbCKlNikgyBdy4dEdu3twARJM+CggCpPNzgAEsOkWwAFcWXAAAEXx5QAAJuSWAAR/MEjQ== Attached is the updated "applied" material (rev. D) with the input I have received thus far. I will incorporate whatever additional input I receive by end of day this Saturday (Aug. 26) and, if any, reissue for the Aug. 30 meeting. This rev. reflects: * John Hall's input (shown as strike-outs and yellow-highlights). * Two minor editor additions. * The agreed rewording (sent by Don - thanks!) for the Annex A material * A new Annex A section that explains "directly enforceable" ~ Keri file: Issue9477-D-applied.doc Issue9477-D-applied.doc 12 Business Rules _____________________________________________________ Vocabulary for Describing Business Rules Language: English Included Vocabulary: Vocabulary for Describing Business Vocabulary _____________________________________________________ 12.1 Categories of Guidance Figure 12.1 ___________________________________________________________________ This diagram is not normative abstract syntax for SBVR, but is for illustration only. ___________________________________________________________________ 12.1.1 Guidance body of shared guidance Definition: all of the elements of guidance within a body of shared meanings body of shared meanings includes body of shared guidance Synonymous Form: body of shared guidance is included in body of shared meanings element of guidance General Concept: proposition Definition: means that guides, defines or constrains some aspect of an enterprise Note: This sense of 'means' (as in 'ends and means', rather than 'is meant as') arises from the Business Motivation Model [BMM]. Note: The formulation of an element of guidance is under an enterprise.s control by a party authorized to manage, control or regulate the enterprise, by selection from alternatives in response to a combination of assessments. body of shared guidance includes element of guidance Synonymous Form: element of guidance is included in body of shared guidance element of guidance is practicable Concept Type: characteristic Definition: the element of guidance is sufficiently detailed and precise that a person who knows the element of guidance can apply it effectively and consistently in relevant circumstances to know what behavior is acceptable or not, or how something is decided or calculated Dictionary Basis: able to be done or put into practice successfully; able to be used, useful [ODE] Note: The sense intended is: "It's actually something you can put to use or apply." Note: The behavior, decision or calculation can be that person's own. Note: Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. Note: A practicable business rule is also always free of any indefinite reference to people (e.g., "you", "me"), places (e.g., "here"), and time (e.g., "now"). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to "tell" time), and (b) external clarification. element of governance Definition: business policy or operative business rule General Concept: element of guidance Definition: element of guidance that is concerned with directly controlling, influencing or regulating the actions of an enterprise and the people in it Dictionary Basis: conduct the policy, actions, and affairs of (a state, organization, or people) with authority: control, influence, or regulate (a person, action, or course of events) [ODE, .govern.] element of governance is directly enforceable Definition: the element of governance is able to be done or acted upon; is practicable Definition: violations of the element of governance can be detected without the need for additional interpretation of the element of governance Concept Type: characteristic Note: 'Directly enforceable' means that a person who knows about the element of governance could observe a relevant situation (including his or her own behavior) and decide directly whether or not the business was complying with the element of guidance. Note: 'Directly enforceable' means that a person who knows about the element of governance could observe a relevant situation business activity (including his or her own behavior) and decide directly whether or not the business was complying with the element of guidancegovernance. Necessity: Each element of governance that is directly enforceable is practicable. Necessity: An element of governance that is not directly enforceable is not practicable. business policy Definition: element of guidance that is not directly enforceable whose purpose is to guide an enterprise General Concept: element of guidance, element of governance Note: Compared to a Business Rule, a Business Policy tends to be: - less structured - less discrete or not atomic - less carefully expressed in terms of standard vocabulary - not directly enforceable. Dictionary Basis: definite course or method of action selected (as by a government, institution, group, or individual) from among alternatives and in the light of given conditions to guide and usually determine present and future decisions [MWUD "Policy" 5a] Necessity: No business policy is a business rule. Example: The policy expressed as "A prisoner is considered to be on a hunger strike after missing several meals in a row." proposition is based on fact type Definition: the proposition is formulated using the fact type Example: The EU-Rent business rule that is expressed as "It is obligatory that each rental specifies a car group." (or, in RuleSpeak, "A rental must have a car group.") is based on the EU-Rent fact type 'rental specifies car group'. 12.1.2 Rules rule Definition: proposition that introduces an obligation or a necessity Dictionary Basis: one of a set of explicit or understood regulations or principles governing conduct or procedure within a particular area of activity. a law or principle that operates within a particular sphere of knowledge, describing or prescribing what is possible or allowable. [ODE] [per proposed resolution to Issue 9579] business rule Definition: rule that is under business jurisdiction General Concept: rule, element of guidance business rule is derived from business policy Synonymous Form: business policy is basis for business rule structural rule Definition: rule that is intended as a definitional criterion Necessity: Each structural rule is a proposition that another proposition is a necessity. Synonym: definitional rule definitional rule See: structural rule structural business rule Definition: structural rule that is a business rule Synonym: definitional business rule Necessity: Each structural business rule is practicable. definitional business rule See: structural business rule operative business rule Definition: business rule that is intended to produce an appropriate or designed effect General Concept: business rule, element of governance Definition: business rule that covers conduct, action, practice, or procedure within a particular activity or sphere Definition: business rule that there is an obligation concerning conduct, action, practice or procedure Dictionary Basis: a prescribed, suggested, or self-imposed guide for conduct or action : a regulation or principle [.] [MWU (1a) 'rule'] Dictionary Basis: a prescribed guide for conduct or action [MWCD 'rule'] Necessity: Each operative business rule is a proposition that another proposition is an obligation. Necessity: No operative business rule is a structural business rule. Necessity: Each operative business rule is directly enforceable. Synonym: behavioral business rule behavioral business rule See: operative business rule 12.1.3 Enforcement level of enforcement Definition: something that represents a position in a graded or ordered scale of values that specifies the severity of action imposed in order to put or keep an operative business rule in force Dictionary Basis: a position on a real or imaginary scale of amount, quantity, extent, or quality [NODE 'level'] Dictionary Basis: compel observance of or compliance with [NODE 'enforcement'] Example: An example set of levels of enforcement, based on [BRG-ODP] Enforcement Level: strict Description: strictly enforced (If you violate the rule, you cannot escape the penalty.) Enforcement Level: deferred Description: deferred enforcement (Strictly enforced, but enforcement may be delayed . e.g., waiting for resource with required skills.) Enforcement Level: pre-authorized Description: pre-authorized override (Enforced, but exceptions allowed, with prior approval for actors with before-the-fact override authorization.) Enforcement Level: post-justified Description: post-justified override (If not approved after the fact, you may be subject to sanction or other consequences.) Enforcement Level: override Description: override with explanation (Comment must be provided when the violation occurs.) Enforcement Level: guideline Description: guideline (suggested, but not enforced.) operative business rule has level of enforcement 12.1.4 Admonitions and Affirmations admonition Definition: element of guidance that is practicable and that is a proposition that there is not an obligation or necessity where, by custom or practice, one might be assumed Note: The purpose of an admonition is to preempt application of "rules" that might be assumed by some members of a semantic community, but are not actually rules admitted by the community. Often, the reason for this assumption in a business is that other, similar, businesses have such rules. Typically, the reason for an explicit admonition is that people in the business have mistakenly applied the non-existent "rule" in the past. Example: (In a bank) There is no rule that a person must be over some given age in order open a savings account: "There is no minimum age for opening a savings account". Example: (In EU-Rent) There is no rule that a rented car can be dropped off only at the return branch specified in the rental agreement: "At the end of a rental, a rental car can be dropped off at any EU-Rent branch". There is a related rule that if the drop-off branch is not the specified return branch, the rental will incur a penalty charge, but the importance of this admonition is that EU-Rent wants its cars back, even if they are in the wrong places. It does not want a branch to refuse to accept a car on the grounds that it is not the specified return branch. Necessity: No rule is an admonition. Necessity: No business policy is an admonition. Necessity: No business rule is an admonition. affirmation Definition: element of guidance that is practicable and that is a proposition that there is a permissibility or possibility where, by custom or practice, one might not be assumed Example: (In a bank) "It is possible that an account balance is negative". Example: (In EU-Rent) "A rental car may be dropped off at any EU-Rent branch, even one that is not its scheduled drop-off branch". Necessity: Each affirmation is a proposition that another proposition is a possibility or a permissibility. Necessity: No rule is an affirmation. Necessity: No admonition is an affirmation. Necessity: No business policy is an affirmation. Necessity: No business rule is an affirmation. On PDF pages 178-179 A.2.3.3 What 'Practicable' Means All business rules (and affirmations and admonitions as well) need to be practicable. Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. If Because an operative business rule is practicable, a person who knows about it can decide directly whether it is being followed when that person observes relevant behavior. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. If a structural rule is practicable, a person who knows about it can also decide directly whether it is being followed when that person observes some relevant outcome from a decision or calculation. A practicable business rule is also always free of any indefinite reference to people (e.g., "you", "me"), places (e.g., "here"), and time (e.g., "now"). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to "tell" time), and (b) external clarification. All these criteria assume that the person understands the business concepts that underlie the business rule. A practicable business rule always imparts ready-to-apply knowledge of the kinds above 'on top' of such concepts. An important best practice for business rules, following naturally from this, is that the underlying business vocabulary/ies must be well developed and well managed. Specifically, each business concept should: o Be individually well defined. o Fit logically into the overall structure of concepts. o Made available to the person in appropriate manner. In addition, each business rule should be directly expressible in the given business vocabulary/ies. These best practices point toward the essential role of business vocabularies in supporting business rules . indeed, the bulk of SBVR is devoted to that area. A.2.3.4 Business Rules that Cannot Be Automated Just because business rules are practicable, this does not imply they are always automatable. Many business rules, especially operative business rules, are not automatable in IT systems. For instance, consider the obligation example given above. , "A Customer who appears intoxicated or drugged must not be given possession of a Rental Car." This distinction is not important within SBVR, which focuses on rules only from the business perspective, regardless of whether the rules could be automated. However, it is obviously important in defining a transformation from business model to PIM. In particular, non-automatable business rules need to be implemented as user activity, supported by procedure manuals or rulebooks. Note: The following sub-clause is new. A.2.3.5 What 'Directly Enforceable' Means All operative business rules need to be directly enforceable. To be enforceable, an operative business rule has to be defined in such a way that violations can be detected. The enforcement regime can then detect violation, take corrective action and (if appropriate) impose penalties on the violators. Elements of governance direct what people do in the business, and they need to be enforceable. Being directly enforceable is what delimits business policy from operative business rule. The importance of this is that when people modeling a business encounter (or need to define) elements of governance in the real world, they need to think about two things. First, is the element of governance directly enforceable . i.e., is it possible to observe what people are doing, and recognize whether they are complying or not, without needing further amplification or explanation of the element of governance? If it is not, then the element of governance is a business policy and the modelers haven.t yet finished the model. They also need to develop operative business rules that are derived from the business policy and are directly enforceable. For example, the EU-Rent element of governance 'rental cars must not be exported' is not sufficiently precise to be enforced. It is a business policy and needs operative business rules through which it can be enforced. For example: o Each rental car must be registered in the country of the local area to which it is assigned after purchase. o The country of registration of a rental car must not be changed. o If a car is at a location outside its country of registration, it may be assigned only to a rental with return location in its country of registration. o If a rental car is at a location outside its country or registration for more than five days, it must be returned to its country of registration. Second, if the element of governance is directly enforceable, it ought to be derived from a business policy. If it is not, the modelers ought to be aware that this is so (and might choose to question whether the rule is appropriate). Date: Mon, 28 Aug 2006 01:19:24 +0200 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: John and Keri Cc: SBVR-FTF Subject: Re: [SBVR] Issue 9477 - updated 'applied' document ("D") Keri, Some people at the London meeting did not agree that the example of "business policy" given in the draft ("A prisoner is considered to be on a hunger strike after missing several meals in a row.") was an acceptable example of a business policy. I suggest that it it is unreasonable to include a contentious example, especially when others are available. The following are examples of business policy from BMM, which I assume are not contentious. EU-Rent: Depreciation of rental cars must be minimized Rental cars must not be exported Rental contracts are made under the law of the country in which the rental pick-up branch is located Pizza Company: Safety in the kitchen, and in the streets, comes first E-business Company: A business representative will personally contact each customer who makes a complaint. Any or all of these could replace the example in the draft. Regards, John John and Keri wrote: Attached is the updated "applied" material (rev. D) with the input I have received thus far. I will incorporate whatever additional input I receive by end of day this Saturday (Aug. 26) and, if any, reissue for the Aug. 30 meeting. This rev. reflects: * John Hall's input (shown as strike-outs and yellow-highlights). * Two minor editor additions. * The agreed rewording (sent by Don - thanks!) for the Annex A material * A new Annex A section that explains "directly enforceable" ~ Keri file: Issue9477-D-applied.doc X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Sun, 27 Aug 2006 19:55:08 -0500 To: john.hall@modelsys.com, John and Keri From: "Ronald G. Ross" Subject: Re: [SBVR] Issue 9477 - updated 'applied' document ("D") Cc: SBVR-FTF At 06:19 PM 8/27/2006, John Hall wrote: Keri, Some people at the London meeting did not agree that the example of "business policy" given in the draft ("A prisoner is considered to be on a hunger strike after missing several meals in a row.") was an acceptable example of a business policy. I suggest that it it is unreasonable to include a contentious example, especially when others are available. John, Inclusion of this example was a condition of the London agreement. I have that in my notes. I believe everyone was clear on that. I presented this explicitly as a BRS "must have" and a condition of moving forward. I was aware that it does not conform to your practice. Therefore, I have suggested several times pulling in a series of other established examples from BMM and/or elsewhere so that this one would not stick out so much for those who have methodology problems with it. We are all going to have to live with things in SBVR that we don't necessarily like. And of course, examples are not normative. Ron The following are examples of business policy from BMM, which I assume are not contentious. EU-Rent: Depreciation of rental cars must be minimized Rental cars must not be exported Rental contracts are made under the law of the country in which the rental pick-up branch is located Pizza Company: Safety in the kitchen, and in the streets, comes first E-business Company: A business representative will personally contact each customer who makes a complaint. Any or all of these could replace the example in the draft. Regards, John John and Keri wrote: Attached is the updated "applied" material (rev. D) with the input I have received thus far. I will incorporate whatever additional input I receive by end of day this Saturday (Aug. 26) and, if any, reissue for the Aug. 30 meeting. This rev. reflects: * John Hall's input (shown as strike-outs and yellow-highlights). * Two minor editor additions. * The agreed rewording (sent by Don - thanks!) for the Annex A material * A new Annex A section that explains "directly enforceable" ~ Keri file: Issue9477-D-applied.doc Date: Mon, 28 Aug 2006 12:16:54 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: "Ronald G. Ross" , SBVR-FTF Subject: Re: [SBVR] Issue 9477 - updated 'applied' document ("D") X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No I wouldn't normally involve myself in such a debate as this, but... Why is "A prisoner is considered to be on a hunger strike after missing several meals in a row" a 'business policy'? Naively, I would have said it is a definition, or at least a 'sufficient condition'. Now, "A prisoner shall be treated as being on a hunger strike after missing several meals in a row", which is probably what was meant, *is* a 'business policy', as I understand the term. Of course, I don't claim to know a business policy from a hole in the ground, but it doesn't seem to me that this example is going to produce any improvement in that situation. Ronald G. Ross wrote: Inclusion of this example was a condition of the London agreement. I have that in my notes. I believe everyone was clear on that. I presented this explicitly as a BRS "must have" and a condition of moving forward. I find it truly amazing that moving forward with SBVR should hinge on including a contentious example, which, as Ron says, is non-normative. We are down to 2 months to produce an FTF Report before the annual drop-dead date, could we please put the non-normative issues on the back burner? -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Mon, 28 Aug 2006 12:28:08 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: "Ronald G. Ross" CC: SBVR-FTF Subject: Re: [SBVR] Issue 9477 - updated 'applied' document ("D") X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No Ed Barkmeyer wrote: Why is "A prisoner is considered to be on a hunger strike after missing several meals in a row" a 'business policy'? Naively, I would have said it is a definition, or at least a 'sufficient condition'. Upon reflection, what is specified here is a characteristic that is not a 'necessary characteristic' under the definition, and may not be generally considered to imply the necessary characteristics for the definition. Stating that such a condition is nonetheless to be considered a 'sufficient condition' does really seem to be a 'business policy'. And the implication: Now, "A prisoner shall be treated as being on a hunger strike after missing several meals in a row", which is probably what was meant, follows directly from that 'policy statement'. So I think I can agree. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Mon, 28 Aug 2006 07:00:01 -0700 Subject: Re: [SBVR] Issue 9477 - updated 'applied' document ("E") From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR] Issue 9477 - updated 'applied' document ("E") Thread-Index: AcbCKlNikgyBdy4dEdu3twARJM+CggCpPNzgAEsOkWwAFcWXAAAEXx5QAAJuSWAAR/MEjQDHKfZv Attached is the updated "applied" material (rev. E) with the input I received by the Sat. (Aug. 26) cutoff. It reflects two changes from the rev. "D" version: * addition of a EU-Rent example of 'business policy' (taken from the new Annex A material) * some minor edits of the new Annex A section. Please send any feedback for discussion at this week's meeting (Wed., Aug 30). regards, Keri file: Issue9477-E-applied.doc On 8/24/06 7:57 AM, "John and Keri" wrote: > Attached is the updated "applied" material (rev. D) with the input I have > received thus far. I will incorporate whatever additional input I receive > by end of day this Saturday (Aug. 26) and, if any, reissue for the Aug. 30 > meeting. > > This rev. reflects: > * John Hall's input (shown as strike-outs and yellow-highlights). > * Two minor editor additions. > * The agreed rewording (sent by Don - thanks!) for the Annex A material > * A new Annex A section that explains "directly enforceable" > > ~ Keri > file: Issue9477-D-applied.doc > Issue9477-E-applied.doc User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Mon, 28 Aug 2006 08:21:17 -0700 Subject: Re: [SBVR] Issue 9477 - updated 'applied' document ("D") From: John and Keri To: "Ronald G. Ross" , John Hall CC: SBVR-FTF Thread-Topic: [SBVR] Issue 9477 - updated 'applied' document ("D") Thread-Index: AcbKtZtM2f1klDaoEduTtAARJM+Cgg== John, Ron, I worked with what I had as of yesterday (Sun.) morning, the timeslot I had allocated to 9477 work. In the document I just sent out, I did include an example for EU-Rent . one that would correspond to the new Annex A material. I have no additional time for rework of 9477 between now and Wed., so if someone (either of you, or anyone else) feels strongly about some point please bring that up for the Wed. discussion. We can no doubt keep this going until the next London meeting. As for removing/replacing the example from Ron: >From my editor-of-9477 perspective, I don.t see it as appropriate to my role to decide to have one person.s input replace another.s. The Team does that on the field of play. >From my personal, fond recollections of the London event (which now appears to have as many variations as there are memories of it), I favor the example Ron provided because it makes a point that I had tried (unsuccessfully) to get tended to. ~ Keri On 8/27/06 5:55 PM, "Ronald G. Ross" wrote: At 06:19 PM 8/27/2006, John Hall wrote: Keri, Some people at the London meeting did not agree that the example of "business policy" given in the draft ("A prisoner is considered to be on a hunger strike after missing several meals in a row.") was an acceptable example of a business policy. I suggest that it it is unreasonable to include a contentious example, especially when others are available. John, Inclusion of this example was a condition of the London agreement. I have that in my notes. I believe everyone was clear on that. I presented this explicitly as a BRS "must have" and a condition of moving forward. I was aware that it does not conform to your practice. Therefore, I have suggested several times pulling in a series of other established examples from BMM and/or elsewhere so that this one would not stick out so much for those who have methodology problems with it. We are all going to have to live with things in SBVR that we don't necessarily like. And of course, examples are not normative. Ron The following are examples of business policy from BMM, which I assume are not contentious. EU-Rent: Depreciation of rental cars must be minimized Rental cars must not be exported Rental contracts are made under the law of the country in which the rental pick-up branch is located Pizza Company: Safety in the kitchen, and in the streets, comes first E-business Company: A business representative will personally contact each customer who makes a complaint. Any or all of these could replace the example in the draft. Regards, John John and Keri wrote: Attached is the updated "applied" material (rev. D) with the input I have received thus far. I will incorporate whatever additional input I receive by end of day this Saturday (Aug. 26) and, if any, reissue for the Aug. 30 meeting. This rev. reflects: * John Hall's input (shown as strike-outs and yellow-highlights). * Two minor editor additions. * The agreed rewording (sent by Don - thanks!) for the Annex A material * A new Annex A section that explains "directly enforceable" ~ Keri file: Issue9477-D-applied.doc Date: Mon, 28 Aug 2006 18:48:38 +0200 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: "Ronald G. Ross" Cc: John and Keri , SBVR-FTF Subject: Re: [SBVR] Issue 9477 - updated 'applied' document ("D") Ron, I wasn't the only one in the room in London who was unhappy with this example, but if it's another 'showstopper' for you, I don't mind leaving it in. However, I think it would be wrong to give the SBVR audience the impression that business policies are usually defined at this level of detail, so I agree that this should not be the only example. I suggested some examples from BMM. including three from EU-Rent. Regards, John Ronald G. Ross wrote: At 06:19 PM 8/27/2006, John Hall wrote: Keri, Some people at the London meeting did not agree that the example of "business policy" given in the draft ("A prisoner is considered to be on a hunger strike after missing several meals in a row.") was an acceptable example of a business policy. I suggest that it it is unreasonable to include a contentious example, especially when others are available. John, Inclusion of this example was a condition of the London agreement. I have that in my notes. I believe everyone was clear on that. I presented this explicitly as a BRS "must have" and a condition of moving forward. I was aware that it does not conform to your practice. Therefore, I have suggested several times pulling in a series of other established examples from BMM and/or elsewhere so that this one would not stick out so much for those who have methodology problems with it. We are all going to have to live with things in SBVR that we don't necessarily like. And of course, examples are not normative. Ron The following are examples of business policy from BMM, which I assume are not contentious. EU-Rent: Depreciation of rental cars must be minimized Rental cars must not be exported Rental contracts are made under the law of the country in which the rental pick-up branch is located Pizza Company: Safety in the kitchen, and in the streets, comes first E-business Company: A business representative will personally contact each customer who makes a complaint. Any or all of these could replace the example in the draft. Regards, John John and Keri wrote: Attached is the updated "applied" material (rev. D) with the input I have received thus far. I will incorporate whatever additional input I receive by end of day this Saturday (Aug. 26) and, if any, reissue for the Aug. 30 meeting. This rev. reflects: * John Hall's input (shown as strike-outs and yellow-highlights). * Two minor editor additions. * The agreed rewording (sent by Don - thanks!) for the Annex A material * A new Annex A section that explains "directly enforceable" ~ Keri file: Issue9477-D-applied.doc Date: Mon, 28 Aug 2006 19:29:03 +0200 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: edbark@nist.gov Cc: "Ronald G. Ross" , SBVR-FTF Subject: Re: [SBVR] Issue 9477 - updated 'applied' document ("D") Ed, I agree generally with what you wrote but, as I said in a response to Ron, I don't mind leaving the hunger striker example in. In response to your final point: we may be able to put most non-normative issues on the back burner, but we have to have good examples. Examples are important in SBVR in helping readers to understand it. They should give readers the "look and feel" of instances of a concept. The hunger strike example is at a fine level of detail. It should not be the only example of a business policy, because that could give readers the impression that business policies are typically formed at this level, whereas they actually go all the way up to strategic level (for example, I think that the major policy decision for a prison wrt hunger strikes is "Do you let a hunger striker die, or do you intervene?") . The example needs to be balanced with others that illustrate the full spectrum of business policies. Regards, John Ed Barkmeyer wrote: I wouldn't normally involve myself in such a debate as this, but... Why is "A prisoner is considered to be on a hunger strike after missing several meals in a row" a 'business policy'? Naively, I would have said it is a definition, or at least a 'sufficient condition'. Now, "A prisoner shall be treated as being on a hunger strike after missing several meals in a row", which is probably what was meant, *is* a 'business policy', as I understand the term. Of course, I don't claim to know a business policy from a hole in the ground, but it doesn't seem to me that this example is going to produce any improvement in that situation. Ronald G. Ross wrote: Inclusion of this example was a condition of the London agreement. I have that in my notes. I believe everyone was clear on that. I presented this explicitly as a BRS "must have" and a condition of moving forward. I find it truly amazing that moving forward with SBVR should hinge on including a contentious example, which, as Ron says, is non-normative. We are down to 2 months to produce an FTF Report before the annual drop-dead date, could we please put the non-normative issues on the back burner? -Ed X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 25 Aug 2006 22:17:40 -0500 To: John and Keri , SBVR-FTF From: "Ronald G. Ross" Subject: Re: [SBVR] Issue 9477 and 9613 - as package elements At 07:40 AM 8/23/2006, John and Keri wrote: On 8/22/06 9:50 PM, "Donald Chapin" wrote: > Keri, > > I'm still hoping that we can put the Issue Resolution for the four packaged > Issues to a vote before the end of the week of Aug. 28 - Sept. 1. Donald, For your planning purposes ... I do not currently have any time available the week of Aug 28 - Sept. 1 to work on SBVR matters. My assessment is that you have introduced a raft of new material for issue 9613. It was not discussed or agreed in London. Based on SBVR history, it could take months to assimilate it all. I appreciate your endless optimism and energy, but we need to be realistic. I would discourage any notion of voting on this stuff. Ron Hmmm... From the perspective of 9613, that seems awfully optimistic. We are still working on coming to a common perspective on the terminology (the first 'component') and haven't even begun to review/grasp the architectural features of the second (the 'rule-less' SBVR component). > I have been told by the OMG that we have a little leeway on getting the SBVR > FTF Report by Monday, Sept 4th. > > It will be much better with the Architecture Board not to have to defer > these key Issues. It would also be better for progress and the morale of > the SBVR FTF team to have these four Issues behind us. But, of course, only with solid understanding and agreement. > In any case, we either have to vote on a Resolution or Deferral of these > four Issues before the SBVR FTF Report can be completed. > > If we can agree on an Issue Resolution, the page numbers will not need to be > changed. Thanks for confirming my understanding that the page numbers would need to be changed if deferred. ~ Keri DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:Reply-To:From:To:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:X-MimeOLE:In-Reply-To; b=cltujbuHhH2kUoq4Bvy46n7mzFMrE0ROaXcg0OVFYuQbNaIFbft+89CDmdbhOQ+Ze22ngyH5JlCQ+i8B/CPdzxRaOa7ac0esA/9IoT2i49aIL/w3d4JPyppmyOC8jJvptWzNRGBb1p/F/kBkMmTrc2cwVHp813D1iDFZ6vF07Zs= ; Reply-To: From: "Donald Chapin" To: "'SBVR-FTF'" Subject: RE: [SBVR] Issue 9477 and 9613 - as package elements Date: Sat, 26 Aug 2006 18:20:13 +0800 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcbIvjxwAxw3+USjSY6mDsjyWRuEGwAOX8pQ Ron, On 26 August 2006 11:18 Ron Ross wrote: > >On 8/22/06 9:50 PM, "Donald Chapin" wrote: > > > I'm still hoping that we can put the Issue Resolution for the four > packaged > > > Issues to a vote before the end of the week of Aug. 28 - Sept. 1. > > Donald, > > For your planning purposes ... I do not currently have any > time available the week of Aug 28 - Sept. 1 to work on SBVR matters. > > My assessment is that you have introduced a raft of new > material for issue 9613. It was not discussed or agreed in London. > Based on SBVR history, it could take months to assimilate it all. > > I appreciate your endless optimism and energy, but we need > to be realistic. I would discourage any notion of voting on this stuff. I would remind you that everything in the draft Issue 9613 Resolution is a direct implementation of one or more principles in the "SBVR Architectural Principles for Definitions & Rules" document or in Ed Barkmeyer's email answering questions posed to him in that document. In the London meeting this document was discussed and revised on screen, principle for principle, with the group not moving to the next principle until there were no more changes to the current one. Donald User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 30 Aug 2006 08:58:17 -0700 Subject: Re: [SBVR] Issue 9477 - updated 'applied' document ("F") From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR] Issue 9477 - updated 'applied' document ("F") Thread-Index: AcbMTRtYWcZQ5DhAEduAiwARJM+Cgg== All, The attached reflects what was discussed/agreed today. I will be using it to write the Edit Instructions (due to Donald by end of day today). Please let me know, asap, if you spot anything I got wrong. Thanks, Keri Issue9477-F-applied.doc 12 Business Rules _____________________________________________________ Vocabulary for Describing Business Rules Language: English Included Vocabulary: Vocabulary for Describing Business Vocabulary _____________________________________________________ 12.1 Categories of Guidance Figure 12.1 ___________________________________________________________________ This diagram is not normative abstract syntax for SBVR, but is for illustration only. ___________________________________________________________________ 12.1.1 Guidance body of shared guidance Definition: all of the elements of guidance within a body of shared meanings body of shared meanings includes body of shared guidance Synonymous Form: body of shared guidance is included in body of shared meanings element of guidance General Concept: proposition Definition: means that guides, defines or constrains some aspect of an enterprise Note: This sense of 'means' (as in 'ends and means', rather than 'is meant as') arises from the Business Motivation Model [BMM]. Note: The formulation of an element of guidance is under an enterprise.s control by a party authorized to manage, control or regulate the enterprise, by selection from alternatives in response to a combination of assessments. body of shared guidance includes element of guidance Synonymous Form: element of guidance is included in body of shared guidance element of guidance is practicable Concept Type: characteristic Definition: the element of guidance is sufficiently detailed and precise that a person who knows the element of guidance can apply it effectively and consistently in relevant circumstances to know what behavior is acceptable or not, or how something is decided or calculated Dictionary Basis: able to be done or put into practice successfully; able to be used, useful [ODE] Note: The sense intended is: "It's actually something you can put to use or apply." Note: The behavior, decision or calculation can be that person's own. Note: Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. Note: A practicable business rule is also always free of any indefinite reference to people (e.g., "you", "me"), places (e.g., "here"), and time (e.g., "now"). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to "tell" time), and (b) external clarification. element of governance Definition: business policy or operative business rule General Concept: element of guidance Definition: element of guidance that is concerned with directly controlling, influencing or regulating the actions of an enterprise and the people in it Dictionary Basis: conduct the policy, actions, and affairs of (a state, organization, or people) with authority: control, influence, or regulate (a person, action, or course of events) [ODE, .govern.] element of governance is directly enforceable Definition: the element of governance is able to be done or acted upon; is practicable Definition: violations of the element of governance can be detected without the need for additional interpretation of the element of governance Concept Type: characteristic Note: 'Directly enforceable' means that a person who knows about the element of governance could observe a relevant situation (including his or her own behavior) and decide directly whether or not the business was complying with the element of guidance. Note: 'Directly enforceable' means that a person who knows about the element of governance could observe a relevant situation business activity (including his or her own behavior) and decide directly whether or not the business was complying with the element of guidancegovernance. Necessity: Each element of governance that is directly enforceable is practicable. Necessity: An element of governance that is not directly enforceable is not practicable. business policy Definition: element of governanceguidance that is not directly enforceable whose purpose is to guide an enterprise General Concept:element of guidance, element of governance Note: Compared to a Business Rule, a Business Policy tends to be: - less structured - less discrete or not atomic - less carefully expressed in terms of standard vocabulary - not directly enforceable. Dictionary Basis: definite course or method of action selected (as by a government, institution, group, or individual) from among alternatives and in the light of given conditions to guide and usually determine present and future decisions [MWUD "Policy" 5a] Necessity: No business policy is a business rule. Example: The policy expressed as "A prisoner is considered to be on a hunger strike after missing several meals in a row." Example: The policy expressed as "The prison medical authority will intervene if a hunger striker's life is in danger." Example: The EU-Rent policy expressed as "Rental cars must not be exported." Example: The policy expressed as "Each customer who complains will be personally contacted by a representative of the company." proposition is based on fact type Definition: the proposition is formulated using the fact type Example: The EU-Rent business rule that is expressed as "It is obligatory that each rental specifies a car group." (or, in RuleSpeak, "A rental must have a car group.") is based on the EU-Rent fact type 'rental specifies car group'. 12.1.2 Rules rule Definition: proposition that introduces an obligation or a necessity Dictionary Basis: one of a set of explicit or understood regulations or principles governing conduct or procedure within a particular area of activity. a law or principle that operates within a particular sphere of knowledge, describing or prescribing what is possible or allowable. [ODE] [per proposed resolution to Issue 9579] business rule Definition: rule that is under business jurisdiction General Concept: rule, element of guidance business rule is derived from business policy Synonymous Form: business policy is basis for business rule structural rule Definition: rule that is intended as a definitional criterion Necessity: Each structural rule is a proposition that another proposition is a necessity. Synonym: definitional rule definitional rule See: structural rule structural business rule Definition: structural rule that is a business rule Synonym: definitional business rule Necessity: Each structural business rule is practicable. definitional business rule See: structural business rule operative business rule Definition: business rule that is intended to produce an appropriate or designed effect and is directly enforceable Definition:business rule that covers conduct, action, practice, or procedure within a particular activity or sphere Definition: business rule that there is an obligation concerning conduct, action, practice or procedure within a particular activity or sphere Definition: element of governance that is directly enforceable General Concept:business rule, element of governance Dictionary Basis: a prescribed, suggested, or self-imposed guide for conduct or action : a regulation or principle [.] [MWU (1a) 'rule'] Dictionary Basis: a prescribed guide for conduct or action [MWCD 'rule'] Necessity: Each operative business rule is a proposition that another proposition is an obligation. Necessity: No operative business rule is a structural business rule. Necessity: Each operative business rule is directly enforceable. Synonym: behavioral business rule behavioral business rule See: operative business rule 12.1.3 Enforcement level of enforcement Definition: something that represents a position in a graded or ordered scale of values that specifies the severity of action imposed in order to put or keep an operative business rule in force Dictionary Basis: a position on a real or imaginary scale of amount, quantity, extent, or quality [NODE 'level'] Dictionary Basis: compel observance of or compliance with [NODE 'enforcement'] Example: An example set of levels of enforcement, based on [BRG-ODP] Enforcement Level: strict Description: strictly enforced (If you violate the rule, you cannot escape the penalty.) Enforcement Level: deferred Description: deferred enforcement (Strictly enforced, but enforcement may be delayed . e.g., waiting for resource with required skills.) Enforcement Level: pre-authorized Description: pre-authorized override (Enforced, but exceptions allowed, with prior approval for actors with before-the-fact override authorization.) Enforcement Level: post-justified Description: post-justified override (If not approved after the fact, you may be subject to sanction or other consequences.) Enforcement Level: override Description: override with explanation (Comment must be provided when the violation occurs.) Enforcement Level: guideline Description: guideline (suggested, but not enforced.) operative business rule has level of enforcement 12.1.4 Admonitions and Affirmations admonition Definition: element of guidance that is practicable and that is a proposition that there is not an obligation or necessity where, by custom or practice, one might be assumed Note: The purpose of an admonition is to preempt application of "rules" that might be assumed by some members of a semantic community, but are not actually rules admitted by the community. Often, the reason for this assumption in a business is that other, similar, businesses have such rules. Typically, the reason for an explicit admonition is that people in the business have mistakenly applied the non-existent "rule" in the past. Example: (In a bank) There is no rule that a person must be over some given age in order open a savings account: "There is no minimum age for opening a savings account". Example: (In EU-Rent) There is no rule that a rented car can be dropped off only at the return branch specified in the rental agreement: "At the end of a rental, a rental car can be dropped off at any EU-Rent branch". There is a related rule that if the drop-off branch is not the specified return branch, the rental will incur a penalty charge, but the importance of this admonition is that EU-Rent wants its cars back, even if they are in the wrong places. It does not want a branch to refuse to accept a car on the grounds that it is not the specified return branch. Necessity: No rule is an admonition. Necessity: No business policy is an admonition. Necessity: No business rule is an admonition. affirmation Definition: element of guidance that is practicable and that is a proposition that there is a permissibility or possibility where, by custom or practice, one might not be assumed Example: (In a bank) "It is possible that an account balance is negative". Example: (In EU-Rent) "A rental car may be dropped off at any EU-Rent branch, even one that is not its scheduled drop-off branch". Necessity: Each affirmation is a proposition that another proposition is a possibility or a permissibility. Necessity: No rule is an affirmation. Necessity: No admonition is an affirmation. Necessity: No business policy is an affirmation. Necessity: No business rule is an affirmation. On PDF pages 178-179 A.2.3.3 What 'Practicable' Means All business rules (and affirmations and admonitions as well) need to be practicable. Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. If Because an operative business rule is practicable, a person who knows about it can decide directly whether it is being followed when that person observes relevant behavior. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. If a structural rule is practicable, a person who knows about it can also decide directly whether it is being followed when that person observes some relevant outcome from a decision or calculation. A practicable business rule is also always free of any indefinite reference to people (e.g., "you", "me"), places (e.g., "here"), and time (e.g., "now"). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to "tell" time), and (b) external clarification. All these criteria assume that the person understands the business concepts that underlie the business rule. A practicable business rule always imparts ready-to-apply knowledge of the kinds above 'on top' of such concepts. An important best practice for business rules, following naturally from this, is that the underlying business vocabulary/ies must be well developed and well managed. Specifically, each business concept should: o Be individually well defined. o Fit logically into the overall structure of concepts. o Made available to the person in appropriate manner. In addition, each business rule should be directly expressible in the given business vocabulary/ies. These best practices point toward the essential role of business vocabularies in supporting business rules . indeed, the bulk of SBVR is devoted to that area. A.2.3.4 Business Rules that Cannot Be Automated Just because business rules are practicable, this does not imply they are always automatable. Many business rules, especially operative business rules, are not automatable in IT systems. For instance, consider the obligation example given above. , "A Customer who appears intoxicated or drugged must not be given possession of a Rental Car." This distinction is not important within SBVR, which focuses on rules only from the business perspective, regardless of whether the rules could be automated. However, it is obviously important in defining a transformation from business model to PIM. In particular, non-automatable business rules need to be implemented as user activity, supported by procedure manuals or rulebooks. Note: The following sub-clause is new. A.2.3.5 What 'Directly Enforceable' Means All operative business rules need to be directly enforceable. To be enforceable, an operative business rule has to be defined in such a way that violations can be detected. The enforcement regime can then detect a violation, and take corrective appropriate action (e.g., correct the violation, notify other parties, and/or (if appropriate) impose penalties on the violators). Elements of governance directly guide govern what people do in the business, and they need to be enforceable. Being directly enforceable is what delimits distinguishes business policy policies from operative business rules. The importance of this is that when the people modeling specifying a business encounter (or need to define) elements of governance in the real world, they need to think about two things. First, is the element of governance directly enforceable . i.e., is it possible to observe what people are doing, and recognize whether they are complying or not, without needing further amplification or explanation of the element of governance? If it is not, then the element of governance is a business policy and the modelers those who are defining the business haven.t yet finished the model. They also need to develop operative business rules, derived from the business policy, that are derived from the business policy and are directly enforceable. For example, the EU-Rent element of governance 'rental cars must not be exported' is not sufficiently precise to be enforced. It is a business policy and needs operative business rules through which it can be enforced. For example: o Each rental car must be registered in the country of the local area to which it is assigned after purchase. o The country of registration of a rental car must not be changed. o If a car is at a location outside its country of registration, it may be assigned only to a rental with return location in its country of registration. o If a rental car is at a location outside its country or registration for more than five days, it must be returned to its country of registration. Second, if the an element of governance is directly enforceable, it ought to be derived from a business policy. If it is not, the modelers business designers ought to be aware that this is so (and might choose to question whether the rule is appropriate). User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 30 Aug 2006 11:50:30 -0700 Subject: Re: [SBVR] Issue 9477 - updated 'applied' document ("F v.2") From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR] Issue 9477 - updated 'applied' document ("F v.2") Thread-Index: AcbMZSpLaJCsnDhYEduAiwARJM+Cgg== All, In looking through the versions of the 'applied' documents and an earlier version of the Edit Instructions, I have spotted an ambiguity. It appears that the intent is to *remove* these Necessities from 'admonition' and 'admonition': Each admonition is a proposition that another proposition is not an obligation or a necessity. Each affirmation is a proposition that another proposition is a possibility or a permissibility. In the earlier Edit Instructions, both were removed but in the evolving 'applied' document, one had been retained. I have revised the mark-up to reflect the removal of both (see p. 6). If someone feels this is wrong, please reply. Thanks, Keri file: Issue9477-F-applied (v.2).doc Issue9477-F-applied (v.2).doc 12 Business Rules _____________________________________________________ Vocabulary for Describing Business Rules Language: English Included Vocabulary: Vocabulary for Describing Business Vocabulary _____________________________________________________ 12.1 Categories of Guidance Figure 12.1 ___________________________________________________________________ This diagram is not normative abstract syntax for SBVR, but is for illustration only. ___________________________________________________________________ 12.1.1 Guidance body of shared guidance Definition: all of the elements of guidance within a body of shared meanings body of shared meanings includes body of shared guidance Synonymous Form: body of shared guidance is included in body of shared meanings element of guidance General Concept: proposition Definition: means that guides, defines or constrains some aspect of an enterprise Note: This sense of 'means' (as in 'ends and means', rather than 'is meant as') arises from the Business Motivation Model [BMM]. Note: The formulation of an element of guidance is under an enterprise.s control by a party authorized to manage, control or regulate the enterprise, by selection from alternatives in response to a combination of assessments. body of shared guidance includes element of guidance Synonymous Form: element of guidance is included in body of shared guidance element of guidance is practicable Concept Type: characteristic Definition: the element of guidance is sufficiently detailed and precise that a person who knows the element of guidance can apply it effectively and consistently in relevant circumstances to know what behavior is acceptable or not, or how something is decided or calculated Dictionary Basis: able to be done or put into practice successfully; able to be used, useful [ODE] Note: The sense intended is: "It's actually something you can put to use or apply." Note: The behavior, decision or calculation can be that person's own. Note: Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. Note: A practicable business rule is also always free of any indefinite reference to people (e.g., "you", "me"), places (e.g., "here"), and time (e.g., "now"). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to "tell" time), and (b) external clarification. element of governance Definition: business policy or operative business rule General Concept: element of guidance Definition: element of guidance that is concerned with directly controlling, influencing or regulating the actions of an enterprise and the people in it Dictionary Basis: conduct the policy, actions, and affairs of (a state, organization, or people) with authority: control, influence, or regulate (a person, action, or course of events) [ODE, .govern.] element of governance is directly enforceable Definition: the element of governance is able to be done or acted upon; is practicable Definition: violations of the element of governance can be detected without the need for additional interpretation of the element of governance Concept Type: characteristic Note: 'Directly enforceable' means that a person who knows about the element of governance could observe a relevant situation (including his or her own behavior) and decide directly whether or not the business was complying with the element of guidance. Note: 'Directly enforceable' means that a person who knows about the element of governance could observe a relevant situation business activity (including his or her own behavior) and decide directly whether or not the business was complying with the element of guidancegovernance. Necessity: Each element of governance that is directly enforceable is practicable. Necessity: An element of governance that is not directly enforceable is not practicable. business policy Definition: element of governanceguidance that is not directly enforceable whose purpose is to guide an enterprise General Concept:element of guidance, element of governance Note: Compared to a Business Rule, a Business Policy tends to be: - less structured - less discrete or not atomic - less carefully expressed in terms of standard vocabulary - not directly enforceable. Dictionary Basis: definite course or method of action selected (as by a government, institution, group, or individual) from among alternatives and in the light of given conditions to guide and usually determine present and future decisions [MWUD "Policy" 5a] Necessity: No business policy is a business rule. Example: The policy expressed as "A prisoner is considered to be on a hunger strike after missing several meals in a row." Example: The policy expressed as "The prison medical authority will intervene if a hunger striker's life is in danger." Example: The EU-Rent policy expressed as "Rental cars must not be exported." Example: The policy expressed as "Each customer who complains will be personally contacted by a representative of the company." proposition is based on fact type Definition: the proposition is formulated using the fact type Example: The EU-Rent business rule that is expressed as "It is obligatory that each rental specifies a car group." (or, in RuleSpeak, "A rental must have a car group.") is based on the EU-Rent fact type 'rental specifies car group'. 12.1.2 Rules rule Definition: proposition that introduces an obligation or a necessity Dictionary Basis: one of a set of explicit or understood regulations or principles governing conduct or procedure within a particular area of activity. a law or principle that operates within a particular sphere of knowledge, describing or prescribing what is possible or allowable. [ODE] [per proposed resolution to Issue 9579] business rule Definition: rule that is under business jurisdiction General Concept: rule, element of guidance business rule is derived from business policy Synonymous Form: business policy is basis for business rule structural rule Definition: rule that is intended as a definitional criterion Necessity: Each structural rule is a proposition that another proposition is a necessity. Synonym: definitional rule definitional rule See: structural rule structural business rule Definition: structural rule that is a business rule Synonym: definitional business rule Necessity: Each structural business rule is practicable. definitional business rule See: structural business rule operative business rule Definition: business rule that is intended to produce an appropriate or designed effect and is directly enforceable Definition:business rule that covers conduct, action, practice, or procedure within a particular activity or sphere Definition: business rule that there is an obligation concerning conduct, action, practice or procedure within a particular activity or sphere Definition: element of governance that is directly enforceable General Concept:business rule, element of governance Dictionary Basis: a prescribed, suggested, or self-imposed guide for conduct or action : a regulation or principle [.] [MWU (1a) 'rule'] Dictionary Basis: a prescribed guide for conduct or action [MWCD 'rule'] Necessity: Each operative business rule is a proposition that another proposition is an obligation. Necessity: No operative business rule is a structural business rule. Necessity: Each operative business rule is directly enforceable. Synonym: behavioral business rule behavioral business rule See: operative business rule 12.1.3 Enforcement level of enforcement Definition: something that represents a position in a graded or ordered scale of values that specifies the severity of action imposed in order to put or keep an operative business rule in force Dictionary Basis: a position on a real or imaginary scale of amount, quantity, extent, or quality [NODE 'level'] Dictionary Basis: compel observance of or compliance with [NODE 'enforcement'] Example: An example set of levels of enforcement, based on [BRG-ODP] Enforcement Level: strict Description: strictly enforced (If you violate the rule, you cannot escape the penalty.) Enforcement Level: deferred Description: deferred enforcement (Strictly enforced, but enforcement may be delayed . e.g., waiting for resource with required skills.) Enforcement Level: pre-authorized Description: pre-authorized override (Enforced, but exceptions allowed, with prior approval for actors with before-the-fact override authorization.) Enforcement Level: post-justified Description: post-justified override (If not approved after the fact, you may be subject to sanction or other consequences.) Enforcement Level: override Description: override with explanation (Comment must be provided when the violation occurs.) Enforcement Level: guideline Description: guideline (suggested, but not enforced.) operative business rule has level of enforcement 12.1.4 Admonitions and Affirmations admonition Definition: element of guidance that is practicable and that is a proposition that there is not an obligation or necessity where, by custom or practice, one might be assumed Note: The purpose of an admonition is to preempt application of "rules" that might be assumed by some members of a semantic community, but are not actually rules admitted by the community. Often, the reason for this assumption in a business is that other, similar, businesses have such rules. Typically, the reason for an explicit admonition is that people in the business have mistakenly applied the non-existent "rule" in the past. Example: (In a bank) There is no rule that a person must be over some given age in order open a savings account: "There is no minimum age for opening a savings account". Example: (In EU-Rent) There is no rule that a rented car can be dropped off only at the return branch specified in the rental agreement: "At the end of a rental, a rental car can be dropped off at any EU-Rent branch". There is a related rule that if the drop-off branch is not the specified return branch, the rental will incur a penalty charge, but the importance of this admonition is that EU-Rent wants its cars back, even if they are in the wrong places. It does not want a branch to refuse to accept a car on the grounds that it is not the specified return branch. Necessity: No rule is an admonition. Necessity: No business policy is an admonition. Necessity: No business rule is an admonition. affirmation Definition: element of guidance that is practicable and that is a proposition that there is a permissibility or possibility where, by custom or practice, one might not be assumed Example: (In a bank) "It is possible that an account balance is negative". Example: (In EU-Rent) "A rental car may be dropped off at any EU-Rent branch, even one that is not its scheduled drop-off branch". Necessity:Each affirmation is a proposition that another proposition is a possibility or a permissibility. Necessity: No rule is an affirmation. Necessity: No admonition is an affirmation. Necessity: No business policy is an affirmation. Necessity: No business rule is an affirmation. On PDF pages 178-179 A.2.3.3 What 'Practicable' Means All business rules (and affirmations and admonitions as well) need to be practicable. Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it. o For an operative business rule, this understanding is about the behavior of people and what form compliant behavior takes. If Because an operative business rule is practicable, a person who knows about it can decide directly whether it is being followed when that person observes relevant behavior. o For a structural rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others. If a structural rule is practicable, a person who knows about it can also decide directly whether it is being followed when that person observes some relevant outcome from a decision or calculation. A practicable business rule is also always free of any indefinite reference to people (e.g., "you", "me"), places (e.g., "here"), and time (e.g., "now"). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to "tell" time), and (b) external clarification. All these criteria assume that the person understands the business concepts that underlie the business rule. A practicable business rule always imparts ready-to-apply knowledge of the kinds above 'on top' of such concepts. An important best practice for business rules, following naturally from this, is that the underlying business vocabulary/ies must be well developed and well managed. Specifically, each business concept should: o Be individually well defined. o Fit logically into the overall structure of concepts. o Made available to the person in appropriate manner. In addition, each business rule should be directly expressible in the given business vocabulary/ies. These best practices point toward the essential role of business vocabularies in supporting business rules . indeed, the bulk of SBVR is devoted to that area. A.2.3.4 Business Rules that Cannot Be Automated Just because business rules are practicable, this does not imply they are always automatable. Many business rules, especially operative business rules, are not automatable in IT systems. For instance, consider the obligation example given above., "A Customer who appears intoxicated or drugged must not be given possession of a Rental Car." This distinction is not important within SBVR, which focuses on rules only from the business perspective, regardless of whether the rules could be automated. However, it is obviously important in defining a transformation from business model to PIM. In particular, non-automatable business rules need to be implemented as user activity, supported by procedure manuals or rulebooks. Note: The following sub-clause is new. A.2.3.5 What 'Directly Enforceable' Means All operative business rules need to be directly enforceable. To be enforceable, an operative business rule has to be defined in such a way that violations can be detected. The enforcement regime can then detect a violation, and take corrective appropriate action (e.g., correct the violation, notify other parties, and/or (if appropriate) impose penalties on the violators). Elements of governance directly guide govern what people do in the business, and they need to be enforceable. Being directly enforceable is what delimits distinguishes business policy policies from operative business rules. The importance of this is that when the people modeling specifying a business encounter (or need to define) elements of governance in the real world, they need to think about two things. First, is the element of governance directly enforceable . i.e., is it possible to observe what people are doing, and recognize whether they are complying or not, without needing further amplification or explanation of the element of governance? If it is not, then the element of governance is a business policy and the modelers those who are defining the business haven.t yet finished the model. They also need to develop operative business rules, derived from the business policy, that are derived from the business policy and are directly enforceable. For example, the EU-Rent element of governance 'rental cars must not be exported' is not sufficiently precise to be enforced. It is a business policy and needs operative business rules through which it can be enforced. For example: o Each rental car must be registered in the country of the local area to which it is assigned after purchase. o The country of registration of a rental car must not be changed. o If a car is at a location outside its country of registration, it may be assigned only to a rental with return location in its country of registration. o If a rental car is at a location outside its country or registration for more than five days, it must be returned to its country of registration. Second, if the an element of governance is directly enforceable, it ought to be derived from a business policy. If it is not, the modelers business designers ought to be aware that this is so (and might choose to question whether the rule is appropriate). Date: Wed, 30 Aug 2006 22:22:17 +0200 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en To: John and Keri Cc: SBVR-FTF Subject: Re: [SBVR] Issue 9477 - updated 'applied' document ("F v.2") Keri, I raised issue 9945 "Admonition and Affirmation are the same concept", but have held back from pursuing it until the decks were cleared of higher-priority issues. Resolving 9945 would be a minor refinement - SBVR could be put into practice with Admonition and Affirmation as distinct concepts. I think that it is fine to remove both the necessities you mention from the current version of SBVR. We can then revisit Admonition and Affirmation in the follow-on FTF. Regards, John John and Keri wrote: All, In looking through the versions of the 'applied' documents and an earlier version of the Edit Instructions, I have spotted an ambiguity. It appears that the intent is to *remove* these Necessities from 'admonition' and 'admonition': Each admonition is a proposition that another proposition is not an obligation or a necessity. Each affirmation is a proposition that another proposition is a possibility or a permissibility. In the earlier Edit Instructions, both were removed but in the evolving 'applied' document, one had been retained. I have revised the mark-up to reflect the removal of both (see p. 6). If someone feels this is wrong, please reply. Thanks, Keri file: Issue9477-F-applied (v.2).doc User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 30 Aug 2006 13:25:03 -0700 Subject: Re: [SBVR] Issue 9477 - updated 'applied' document ("F v.2") From: John and Keri To: John Hall CC: SBVR-FTF Thread-Topic: [SBVR] Issue 9477 - updated 'applied' document ("F v.2") Thread-Index: AcbMcl+qngfG8DhlEdu4AAARJM+Cgg== On 8/30/06 1:22 PM, "John Hall" wrote: > Keri, > > I raised issue 9945 "Admonition and Affirmation are the same concept", > but have held back from pursuing it until the decks were cleared of > higher-priority issues. Resolving 9945 would be a minor refinement - > SBVR could be put into practice with Admonition and Affirmation as > distinct concepts. > > I think that it is fine to remove both the necessities you mention from > the current version of SBVR. > > We can then revisit Admonition and Affirmation in the follow-on FTF. Thanks, John, for this confirmation. regards, ~ Keri User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Wed, 30 Aug 2006 13:30:05 -0700 Subject: Re: [SBVR] Issue 9477 - Resolution From: John and Keri To: SBVR-FTF Thread-Topic: [SBVR] Issue 9477 - Resolution Thread-Index: AcbMZSpLaJCsnDhYEduAiwARJM+CggADelgO Attached is the Resolution write-up for Issue 9477, per today's meeting discussion/agreement. The .eps for the updated Figure is also attached. Please reply ASAP (today) if you spot any errors. thanks, Keri file: Issue9477-F.doc file: Issue9477-Fig12.1CatGdnc.eps Issue9477-F.doc Date: Tue, 05 Sep 2006 12:50:07 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: SBVR-FTF Subject: Re: [SBVR-FTF] -- DRAFT SBVR FTF Report - Feedback by End of Day WEDNESDAY, SEPTEMBER 6th] X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No John and Keri wrote: On 9/4/06 10:33 AM, "Donald Chapin" wrote: Team -- Attached is the draft SBVR FTF Report for the first SBVR FTF which will end on October 6th. ... Issues 9477 and 9444 each provide an updated Figure 12.1. It needs to be made clear which is the most recent -- i.e., the Figure that accompanies 9477 is the later version. (In the Report, the material for 9444 appears *after* 9477 meaning that sequential processing through the Edit Instructions will produce a 'lost update' situation.) Yes. The resolution to one of them should refer to the Figure provided by the other. E.g. "The changes to figure 12.1 are incorporated in the replacement Figure given in Issue ..." -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, Actionable v5.doc