Why Use Business Modeling?

This chapter is from the book

Business Models: A Guide for Business and IT

Learn More Buy

This chapter is from the book

This chapter is from the book 

Business Models: A Guide for Business and IT

Learn More Buy

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 the³⁶ 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 discovered³⁷ 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 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.³⁸ 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.