Home > Articles

This chapter is from the book

Business Rules: Precision vs. Handwaving

Alice carefully released the brush, and did her best to get the hair into order. "Come, you look rather better now!" she said, after altering most of the pins. 'But really you should have a lady's maid!

"I'm sure I'll take you with pleasure!" the Queen said. "Twopence a week, and jam every other day."

Alice couldn't help laughing, as she said, "I don't want you to hire me—and I don't care for jam."

"It's very good jam," said the Queen.

"Well, I don't want any to-day, at any rate."

"You couldn't have it if you did want it," the Queen said. "The rule is, jam to-morrow and jam yesterday—but never jam to-day."

Lewis Carroll, Through the Looking Glass [C1872]

The success (or otherwise) of a business system is determined by the handling, that is, discovery, specification, management, and realization, of "business rules." We will start with a definition of a business rule.

Most importantly, we want to be able to determine whether a specific business rule does or does not hold. Thus, we can say that a business rule is a proposition about business things, actions applied to them, and relationships between these things and actions. "Proposition" is a technical term defined in RM-ODP as an observable fact or state of affairs involving one or more entities of which it is possible to assert or deny that it holds for those entities [RM-ODP2]. Essentially the same definition of proposition is used in mathematics (e.g., in [GS1993]) and in logic (e.g., "A Proposition is, a perfecte sentence spoken by the Indicatiue mode, signifying either a true thyng, or a false," in T. Wilson Logike [1580]). A proposition, in Karl Popper's terminology, offers an opportunity for refutation.

Thus, a narrative (a story) is usually not a proposition and, therefore, not a business rule (although it may include propositions). A collection of examples is also not a proposition, nor is a prototype. In these cases, we may "figure out" a proposition or several propositions (and, therefore, a business rule or rules) from this information. Different readers of the information may "figure out" somewhat different propositions. In order to handle this unpleasant situation, we need to make the proposition(s) explicit.

We always encounter propositions in our life and in our work. They may be very specific (such as "the balance of the checking account number 64642136423784 in Bank XVCHAHJ is equal to USD 24,984.32 as of 1/1/2001" or "the fee for maintaining a checking account with a minimum balance per month less than USD 2,000.00 in Bank XVCHAHJ equals USD 7.50 per month"), more generic but still business-specific (such as "an account is a composite in a composition of owners [an owner is a subtype of a party], indicative information [composed of the kind of account, currency, etc.], initial balance, and transaction entries"), or very generic (such as "a subtyping is a relationship between a supertype and at least one subtype such that an instance of a subtype has all the properties of its supertype and may have some additional [subtype-specific] properties"). The last proposition always holds, while the first three may or may not hold.

The structure of a proposition, and thus of a business rule, is more important than its specific content. For example, the structure of all business rules about bank fees determined by account balances is the same (or similar), although the content is clearly different. Similarly, the structure of all business rules about discounts, commissions, and the like—in appropriate contexts—is the same (or similar), although the specific content is different. Moreover, the structure of a business rule is usually stable (defined by its invariant), while the specifics may change often or not so often.

A good specification of an action is also a proposition. However, a caveat is in order: to understand such a specification (and to be able to determine whether it does or does not hold), we need to make explicit the specification of the business domain in the context of which the action happens. As in programming, it is desirable to define data before using it. The business domain specification includes the most important business rules—the invariants of the domain.

We may be told that for simple action specifications we do not need an explicit domain specification because "everyone knows what it means." This statement is incorrect because when we write or read an action specification, we always refer—either explicitly or in our mind—to the specification of the36 context of this action, i.e., to the appropriate domain specification, and we want to assure that the domain specification is understood in the same manner by all stakeholders for various action specifications used in the context of that domain. This assurance is possible only when the domain specification is explicit, i.e., when the context is rendered as text [S1999]. This may not be easy, because some things in a business are not explicit. Some business communications, in particular, may not even be considered as meaningful by some participants. For example, a wave of the hand signifying the acceptance of an offer in contractual negotiations may not be perceived as meaningful information by a participant or observer who is not "in the know."

Successful business modelers always articulate the need for articulation: the contexts of all actions, the elements of business communications, and the nature of their composition are essential for understanding the actions and business communications, and must be discovered37 and formulated by the collective efforts of the modelers and SMEs.

Challengeable Well-Defined Statements

A precise and explicit specification in which everything has been articulated still must be validated by the SMEs. This is easy because such a specification is composed of challengeable well-defined statements (propositions, see above), so that the SME who thinks that some of these statements are wrong just points to these statements and explains what specifically is wrong. In other words, a draft of a precise specification does not need to be correct; in fact, a specification can be considered as a question: "Is this a correct and complete model of your business; and if not, what needs to be changed?" Clearly, an answer to this question is possible only when the specification is precise.

As an example, the simple specification below shows the investments that an individual investor has with a financial institution. These investments are composed of accounts of various kinds. These accounts have common properties shown in their supertype, "account." The existence of a cash account is a prerequisite for any other account shown here, and some properties of these other accounts are determined by the properties of the cash account. Each customer must have at least one cash account (and may have more than one), but may have at most one margin account and at most one short sales account, provided that a margin account exists. Other accounts are also possible. All previous statements in this paragraph are well-defined and can be challenged by the business SMEs. Some of these statements may be considered incorrect by the SMEs (for example, it may happen that a short sales account may exist even if a margin account does not exist for this customer), while some statements may be considered incomplete (for example, some important types of accounts with their specifics may be missing).

This approach of precision over correctness is not restricted to business specifications. It is championed in a much more general philosophical setting by Bunge's insistence not to put the cart of truth before the horse of meaning [B1990b]. The SME's rejection of a fragment of a specification based on the incorrectness of that fragment is a good symptom of modeling success: it means that the SMEs understood the specification and were able to point to errors. The alternative is much worse: continuous apparent acceptance of specifications by the SMEs may be a symptom of "glazing over" due to excessive complexity or vagueness of those specifications so that it was impossible to point to specific errors. Although the SMEs may agree with the specific stories and examples, they are unable to agree or disagree with the generalizations of these stories and examples that remain implicit and exist only in the heads of the analysts and others who make these possibly wrong or mutually inconsistent generalizations.

Figure 6Figure 6

Let us recall in this context that Peter Naur proposed in 1968 [SE1969] to use the work of Christopher Alexander long before it became fashionable to refer to it as a source of ideas about attacking the software design problem. Naur justified his choice by the fact that Alexander was concerned with the design of large heterogeneous constructions. Indeed, Alexander emphasized in The Timeless Way of Building that "...a pattern defines an invariant field which captures all the possible solutions to the problem given, in the stated range of contexts... the task of finding, or discovering, such an invariant field is immensely hard... anyone who takes the trouble to consider it carefully can understand it... these statements can be challenged because they are precise" [A1979]. In business modeling, discovering invariants is hard, but it does not have to be immensely hard because we can, and do, reuse various existing business patterns defined by their invariants. Other than that, Alexander's approach is valid and has been used extensively in business modeling, specifically when the stakeholders (especially the SMEs), as suggested by Alexander, consider carefully, challenge, and validate the business specifications.

Contrariwise, warm and fuzzy feelings represented in stories are not definitions. As Wittgenstein observed in his Tractatus, "The silent adjustments to understand colloquial language are enormously complicated" [W1933]. This is an excellent explanation of failures caused by statements like "Everyone knows what XXX means," or "They [the developers] will figure it out."

Common Explicit Modeling Concepts

"Well, now that we have seen each other," said the Unicorn, "if you'll believe in me, I'll believe in you. Is that a bargain?"

"Yes, if you like," said Alice.

Lewis Carroll, Through the Looking Glass [C1872]

We often hear (and sometimes speak) about the apparently insurmountable communication gap between business subject matter experts (SMEs) and information technologists; or about the equally apparently insurmountable gap between (business and) IT specifiers and IT implementors. In 1969, the significance and extent of the communication gap between different participants in the computing science and software engineering professions was the most important discussion topic at the second (Rome) Software Engineering conference [SE1970].

To try to bridge this communication gap if it exists, the parties need to speak semantically the same language, i.e., to share the same concepts.38 In some cases, the perceived gap exists just because the parties use different terminology to express essentially the same ideas. In other cases, however, the concepts are, or appear to be, semantically different.

Common specification concepts have been around for a long time. Most basic ones come from mathematics. Different specification areas—such as various business and IT system specifications—may have used systems of differently named concepts to express the same semantic structures. At the same time, some concepts used in specifications have not been explicitly formulated. The "true nature" (Dieudonn ) of these concepts may have been understood and formulated only relatively recently. In the same manner as classical mathematics explicates and formulates such concepts used in science and engineering, "conceptual mathematics" (Lawvere/Schanuel) explicates and formulates at least some concepts used in understanding and specifying (the shape of) large systems. In either case, we are not dealing with collections of isolated concepts; we use systems of interrelated concepts instead. More pragmatically, many of these concepts and the relationships between them have been defined in RM-ODP, and we describe and use them throughout the book. This usage permits us to discover generalizations and drastic simplifications: we may and do use the same general approach in different areas instead of being intellectually drowned in a sea of numerous special cases.

The most important concepts here are those that deal with structuring—organizing intellectually—a large amount of information. Specifications that describe various systems are written for humans, so understandability by humans is the objective of such structuring of specifications. It permits us to avoid the "too much stuff" syndrome that has been among the most important reasons of IT system failures.

We use specifications to understand and describe the semantics of existing systems, of future state(s) of such systems, or of new (planned) systems.

"Semantics" Means "Meaning"

We should separate the semantics of a subject matter from its representation. In fact, having more than one representation helps; as Gasparov noted in [G2000], in order to understand a subject matter, its description must be translated into another language. We are using in this book both a stylized (also known as "regimented") English and a graphical representation; experience suggests that both representations are needed and useful in demonstrating a business specification to its customers. Moreover, when a graphical representation is described as a stylized English narrative, the semantics of that graphical representation may become clearer as a result of such translation, and errors in that representation may be discovered and corrected. Finally, not everything can or should be conveniently represented graphically; and there may, of course, be various, more or less convenient, graphical representations (they existed before UML and will exist after).

Thus, when an analyst discusses with the SME the business fragments of interest, the resulting specification re-represents the semantics of the subject matter from the business-specific language of the SME (which could be understood only if the defaults of the writer and of the reader are the same) into a neutral and much more explicit specification language. Often this specification language is a mix of graphical and stylized English representations such that each representation element (and specifically each graphical representation element) has clear and explicitly defined semantics. The same approach should be used with respect to the English narrative: all terms should be well-defined. This is possible, and the English text of RM-ODP is a good example: each term is either defined in the standard itself or is considered to be defined as in "normal English usage." The source of the latter is the Oxford English Dictionary.

Precise Is Not the Same as Detailed

Intellectual discipline requires precision and explicitness. The details—such as the specific individuals participating in a structure—are abstracted out; but the essential—such as the properties of that structure—ought to be formulated in such a crisp manner that it could be understood without ambiguity. This formulation may require sometimes rather substantial effort. And here we see the difference between being able to write a specification and being able to read it. Writing a specification is usually more difficult than reading, but the writer's effort pays off by creating a specification understandable to a large(r) audience. To quote E.W. Dijkstra, "[i]f your text is going to be studied by 60 people and by pondering almost an hour about a turn of phrase that saves your average reader more than a minute, your hour has been well-spent. ... There is only one respectable way of improving your text, viz. by being as clear as possible." [D1986]. It is well-known that a shorter—and crisper—text is more difficult to write than a lengthier one with the same semantics. Clearly, the reader also ought to put some effort in reading and understanding the text!

RM-ODP widely used throughout this book is a good example of a crisp and short text written in carefully phrased stylized English. The foundations of RM-ODP describe the basic concepts and constructs used to specify any system. These foundations are only 18 pages long and require some effort for their reading and understanding. At the same time, the effort to write the foundations took several calendar years of work by a distributed team of world-class experts.

The Algol60 Report is a perhaps less well-known example of an excellent crisp and short text describing in a formal and semi-formal—but rigorous—manner the syntax and semantics of a powerful and elegant programming language. The rigorous semantics of Algol60 is written in stylized English. E.W. Dijkstra noted in his Turing Award Lecture that few documents as short as this have had an equally profound influence on the computing community.

Papers by C.A.R. Hoare—such as Software—barrier or frontier? [H1999]—are an excellent example of presenting the essence of non-trivial IT concepts to a broad audience of non-specialists in this subject matter, including business managers. These short and crisp papers ignore details (that may, for example, change from one buzzword to another) and emphasize the semantics of the invariant properties of software in various contexts.

A clear and crisp business specification may demonstrate the essence—without any details whatsoever—of a business domain in a very small number (five or less) of understandable and elegant diagrams. Such a precise specification demonstrably serves as a conceptual framework for discussions by business decision makers (including discussions at the board level). Some of these discussions may lead to decisions about business process change. Some examples from finance include specification and execution of complex contracts like initial public offerings [K1999], mortgage-based securities, handling of a customer's equity margin account with an emphasis on margin calls, and support of a single-strategy-based customer's position. Some business transformation examples from the publishing industry were presented in [TS1999]. (Of course, when required, the fragments of interest of the high-level business domain specification become refined and discussed in the same manner. The examples from finance referred to above have themselves been obtained by appropriate refinements of business information models similar to the one shown in [K2001].)

As a final example, we may again consider Dijkstra's approach of calculating, i.e., manipulating uninterpreted formulae when reasoning about specifications and programs. This manipulating deals explicitly with the structure of the formulae while consciously ignoring the nature of the specific contents. Using the formal laws of operations on these structures leads to a substantial intellectual economy. It successfully scales up, thus letting us keep sophisticated systems under control [D1997]. We all learned this in elementary school when we were taught that the laws governing operations on numbers are the same for the numbers of apples and the numbers of oranges. We later learned that the same laws apply not only to operations on natural numbers but to operations on other kinds of numbers, and to operations on objects other than numbers. And we have also learned that the same laws—invariants—determine the stable properties of analogous structures no matter what elements participate as members of these structures. This approach helps us to concentrate on the essential, rather than on a huge amount of accidental details, when we look at various problems and their proposed solutions.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020