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

Basic Structuring Constructs

Let us look at a couple of small examples that will lead us to the basic structuring constructs used in specifications.

An Example: Two Simple Relationships

"...grammar is substantially the same in all languages, although it may vary accidentally."

Roger Bacon (1214?-1294?)

The diagram²⁶ on this page demonstrates that a project participant should be exactly one of an employee or a consultant, and at the same time, should be at least one of technical, managerial, or clerical (some managerial employees may also be technical, for example). We see that things are shown as named rectangles, and relationships are shown as named triangles with lines connecting the triangle with the participants of the relationships. The essential properties of the relationship are shown in the triangle.

So far so good. We observe that a specific technical project participant has all the properties of a project participant and some additional properties specific to a technical, but not to a managerial or a clerical, project participant (unless, of course, that technical project participant is also a managerial or a clerical one).

We also observe that the shapes (relationships) of the situation shown in the diagram above are repeated in many other situations. And we observe that putting that many words in a triangle is "too much;" the same words are repeated again and again in many triangles. So we decide to abstract and abbreviate.

Both relationships shown above are subtyping relationships: an instance of a subtype has all the properties of its supertype and some additional, subtype-specific, properties. The kinds of these two subtyping relationships are somewhat different; the subtypes in the "employee-consultant" relationship are exhaustive, so that an instance cannot satisfy the properties of both subtypes at the same time (an employee cannot be a consultant within the same project); but the subtypes in the "technical-managerial-clerical" relationship are overlapping, so that an instance can (but does not have to) have properties of two or even three of the subtypes at the same time. And finally, we observe that these two subtyping relationships themselves are different because they use different criteria for subtyping: employment status and job classification, correspondingly. We may, if we wish (or if the customer wishes), attach the subtyping criteria as names (labels) of these relationships.²⁷ The semantics of our very small business fragment obviously requires us to show two, rather than one (or five!) subtyping relationships.

Figure 1

The abbreviations that we use are determined by the language used and by its (graphical) representation. This book uses UML?—the Unified Modeling Language. It is a standard adopted by the Object Management Group and widely used in the IT industry; there are hundreds of books describing UML. However, the complete language as it currently exists is huge and may be considered overwhelming by business people. We will use only a small subset (see Appendix A) essential to represent the semantics of our specifications. Here is the same specification in UML, where a triangle without a name is used to abbreviate the subtyping relationship.

Figure 2

As shown in this figure, the distinction between the overlapping and non-overlapping subtyping relationships is shown by means of using the "stereotype"²⁸ ?overlapping? where needed; the non-overlapping is the default for subtyping and is not shown. Similarly, the exhaustiveness of the subtyping relationships, that is, the property that all subtypes are enumerated (and there are no other subtypes) is not explicitly shown because it is the default property. Thus, the default characteristics, encountered much more often than non-default ones, are precisely specified, but are not shown at all in the representations, leading to more concise diagrams.

From Specifics to Explicit Models

While examples often introduce a large amount of details, the underlying essentials are usually rather simple. Discovering these essentials may not be easy. By abstracting, that is, by suppressing the irrelevant details, we can determine and formulate the important commonalities between concepts and constructs from apparently different business or technological areas. The same approach is used when we have an incompletely specified problem; we consider a class of problems and thus concentrate on the essential similarities between the elements of this class.²⁹ In other words, we generalize, that is, we concentrate on the supertype rather than on its multiple and various subtypes. In this manner, abstract concepts have been discovered and reused, and abstraction is the ultimate in understanding and reusability (Mac an Airchinnigh). By using abstraction, we may discover, understand, and specify the basic structure of a business domain or its fragment.

Sometimes we have to pay a price for doing so. When we generalize, we often introduce concepts and terminology absent in the specific situations. These concepts and terminology may be new and unfamiliar to the experts in a particular subject area. In some cases, the experts do not even have a term for the concept ("yes, we know about it, but we don't have a name for it"). The explicit formulation of the abstract concepts, together with consistent and explicit usage of their names, may be unconventional, but becomes very convenient for clarity in understanding and reasoning. In this manner, reasoning is reduced to a doable amount [D1976a]. Time and effort may be required to get used to such an approach, but it certainly pays off.

As an example, consider the discovery of numbers and their positional representation: in ordinary arithmetic, we calculate, i.e., manipulate uninterpreted formulae. We do not justify the manipulations by referring to the perceived properties of things, such as apples or dollars, denoted by their symbols. "Hilbert the formalist showed that such interpretation was superfluous because which manipulations were permissible could be defined in terms of the symbols themselves" [D2000]. Similarly (and more generally), Bunge observed that "interesting problems of interpretation of contemporary scientific theories can be tackled almost like calculations, without resorting to arguments from analogy or authority" [B1990b].

As another example, consider one of the main topics of this book: the commonality of concepts and constructs used in business, IT system, and technological specifications. Some of these essential basic concepts, such as invariant, type, or template, as well as the basic structure of such relationships as composition and subtyping, are described in RM-ODP. Similarly, and on a more foundational level, commonly used concepts and structures have been discovered and precisely defined in mathematics, notably in category theory. Although these concepts may have been perceived as second-degree abstractions, they have in fact been successfully taught to high school students [LS1997], and have helped in successful elucidation of important specification properties, specifically in showing how to put seemingly very different things together. It was shown that change of notation (that is, a mapping between sign systems) and refinement should preserve essential structures. In particular, the quality of metaphors including user interfaces is determined by the degree to which structures are preserved [G1999].

We should not forget, of course, that a concept—like a specific thing or an action—does not exist in isolation. A single concept by itself may be valuable but often is insufficient. To quote Lawvere, one of the founding fathers of modern category theory, "comparing reality with existing concepts does not alone suffice to produce the level of understanding required to change the world; a capacity for constructing flexible yet reliable systems of concepts is needed to guide the process."

Discovering and describing a system of simple and elegant concepts is difficult. Understanding and using such a system is much easier, just by virtue of its simplicity and elegance. A system of such RM-ODP concepts as type, class, template, invariant, composition, and so on, successfully has been introduced to and used by business experts in various areas including those traditionally considered to be quite far from mathematics. Even in a business area where specific business patterns have not yet been discovered, it is always possible to use these fundamental concepts as a basis for modeling and eventual discovery of more specific patterns. This solid foundation will never let you down.

From Lines Between Boxes to a Precise Specification

Let us consider another example that will demonstrate two additional kinds of relationships. These two kinds of relationships, together with the subtyping relationship shown above, are the basic structuring constructs encountered in all kinds of specifications.

In an insurance environment, an application for some kind of insurance is to be "underwritten," i.e., assessed by an underwriter taking into account the information in the application and other information available about the specific applicant and situation. The underwriter either accepts the application (which implies creation of an insurance contract between the applicant and the insurance company with the subject matter described in the application), or rejects it (which implies either conducting additional negotiations between the applicant and insurance company, or terminating the specific relationship among the applicant, the insurance company, and the application). An application for insurance creates a "case folder" into which the application and additional information will be put. In turn, the case folder is "assigned to" an underwriter.

It may seem that the following UML diagram would be a faithful representation of the most important aspects of this situation:

Figure 3

However, this diagram shows almost no semantics. Its creators assume that "everyone knows what 'assigned to' means." This meaning might be somehow invented, named "business rules," and realized by the IT developers to be then forever hidden in the code. The information about this specific small fragment of the insurance business domain is not presented in the diagram; rather, it is still in the head of (for example) the underwriter. Nevertheless, the diagram above may be perceived as a specification, while in fact it is not.

In order to prevent such misperceptions, among other things, the language used to represent specifications should enforce appropriate representations. In other words, it should not permit semantic-free elements to be considered as valid expressions in that language. Similarly, as noted by C.A.R. Hoare, a programming language is distinguished not so much by what it empowers a programmer to express, but rather by what it prevents him from expressing.

A precise specification ought to explain (in any representation, whether graphical or textual) the meaning of 'assigned to' and may look like this in UML:

Figure 4

This diagram expresses the following. First, some characteristics of the Underwriter's Work are determined by the characteristics of the Underwriter (shown by the reference relationship from the Underwriter's Work to the Underwriter). Second—more important—a Case Folder is a component of an Underwriter's Work; the Underwriter's Work must exist in order for a Case Folder to exist (shown by the composition³⁰-subordination relationship between the Underwriter's Work and the Case Folder); and the composition-subordination is hierarchical, so that a Case Folder may be a part of the Underwriter s Work of only one Underwriter (shown also by the black diamond rather than by a white one).³¹ This diagram, by virtue of using the composition relationship, shows a very important fact—that there are some properties of the Underwriter's Work determined collectively by the properties of its Case Folders. The modeling process participants may want to discuss the specifics of these properties and, for example, may be interested in the maximum amount of Case Folders included in the Underwriter's Work; presumably this amount is determined not so much by the number but by the complexity of the Case Folders.

From Details to Clear Big Pictures

"...And yet it was a very clever pudding to invent."

"What did you mean it to be made of?" Alice asked, hoping to cheer him up, for the poor Knight seemed quite low-spirited about it.

"It began with blotting paper," the Knight answered with a groan.

"That wouldn't be very nice, I'm afraid—"

"Not very nice alone," he interrupted, quite eagerly: "but you've no idea what a difference it makes mixing it with other things such as gunpowder and sealing-wax. ..."

Lewis Carroll, Through the Looking Glass [C1872]

Discovering similarities between individuals and reasoning in terms of these similarities is not the only way to simplify and understand complex systems. We often want to suppress the details about parts of the whole and concentrate only on the whole itself. As in the roadmap example, when we need to get from here to there, we want to have a clear big picture of where we are in the context of what is around, and where we can (or have to) go. Of course, we cannot directly obtain such a picture from a set of very detailed roadmaps; we need to compose that picture from its components. In order to do that, we choose the appropriate components and combine them in a particular way. This combination includes ignoring the details that are of no interest for the business of looking at the whole. And because different businesses are interested in different aspects of the whole, different compositions of the same whole concentrate on (and ignore) different collective properties of the parts.

A traveling customer of a bank can easily obtain a non-collateralized loan to buy goods or services, even in a foreign country, just by using a credit card. In this manner, the world banking system is at the service of such a customer, and the details of the credit card (such as its issuer, the country of issuance, the currency of issuance, and so on), as well as of the business that provides such a loan, are of no importance. Moreover, the same customer may, by using an ATM (and usually paying a small fee), demand repayment of a part of the customer's loan to the bank (in accordance with the contractual terms of the customer's account). Again, the world banking system is at the service of such a customer, and the details of the account (such as its issuer, the country of issuance, the currency of issuance, and so on), as well as of the business (usually a bank) that accomplishes such a repayment, are of no importance. In this manner, by virtue of entering into contracts with a specific bank, the customer appears to use the world banking system as a counterparty in various transactions, without going into any detail whatsoever about that system and its structure.

As another interesting example, consider the "fast save" functionality of a popular word processor. On the one hand, the composite result of multiple executions of "fast save" appears to be the same as the composite result of multiple executions of ordinary "save" operations. Therefore, it seems that, at a certain abstraction level, it does not matter whether the "save" is fast or not, and in fact it may be preferable to use "fast save" because it is faster. On the other hand, at a lower abstraction level, a "fast save" saves only the changes to a file that become components of the file. Information about the existence and contents of the components at this lower abstraction level may become visible to the reader of the file at a higher level who accesses that file using simple software tools different from the word processor. Because some document authors may not want to make the complete history of updates (including deletions) to their documents available to readers (because of possible serious undesirable consequences), an explicit—and very simple—information model of document components and processing of their versions would help in understanding and making decisions about using the appropriate kind of "save."

As still another example, consider the portfolio approach to investments—be they a collection of retirement investments or a collection of IT project investments [S2001a]. In either situation, we deal with a composition of investments with different risks and rewards. By considering the investments as components of a portfolio rather than each investment in isolation, we can optimize the desirable properties of the composite in this composition (e.g., stabilize the risk), as well as determine the commonalities between some or all components, rather than concentrate on trying to deal only with the specifics of each component.³² The same approach is used for calculating the properties (including risk characteristics) of and making decisions about a position of a customer (having a single strategy or several strategies) or of a trader in financial instrument trading.

Or consider a book (or another document) with many small errors. Although each of these errors may be of little consequence when considered in isolation, their "cumulative effect is to destroy a knowledgeable reader's confidence in the author's standards of accuracy" [R2001]. The cumulative effect here is, of course, the property of the composite determined by the properties of the components and by the way these components are combined.

Different ways to choose and compose parts result in different kinds of clear big pictures of the same whole. In our roadmap example, we may be interested in the political subdivisions of the parts and the whole, or in the existence of multiple interesting parts between here and there (where "interesting parts" and "between" may be defined in various ways), or simply in the minimal time needed to cover the distance. Different compositions will be used to specify whatever we are interested in. In all cases, we are constrained (or encouraged) by the rules of traveling from here to there using a chosen transportation mechanism. Similarly, a clear big picture is obtained from its details by using the (generic and specific) rules of composition and by satisfying the general business rules of the domain of which that composition is itself a part.

Three Basic Kinds of Relationships

We have used three basic kinds of structuring constructs or relationships: subtyping, composition, and reference. Let's summarize what each of these kinds of relationships means. The complete definitions of these kinds of relationships are provided in Appendix B.

A subtyping relationship is between a supertype and its subtype(s). An instance of a subtype has all the properties of its supertype and some additional, subtype-specific properties.

A composition relationship is between a composite and its components (in other words, between the "whole" and its "parts"). Some properties of the composite are determined by properties of its components and by the way these components are combined.

A reference relationship is between reference and maintained instances. Some properties of the maintained instance are determined by properties of its reference instance.

Each of these kinds of relationships—business patterns—may be specialized (we have seen, for example, overlapping and non-overlapping subtyping relationships, as well as different kinds of composition), and the complete definitions of these specializations are also presented in Appendix B. At the same time, we observe that the three kinds of relationships discussed here are generic, that is, they are used everywhere, in all kinds of specifications. Various versions of their definitions have been known for millennia and have been formulated in terms of properties of their participants. The definitions used in this book are essentially the same as in international standards—the Reference Model of Open Distributed Processing (RM-ODP) and the General Relationship Model (GRM).

Using and Overusing Examples

When a number of drawings are made after one pattern, though they may all miss it in some respects, yet they will all resemble it more than they resemble one another; the general character of the pattern will run through them all; the most singular and odd will be those which are most wide of it; and though very few will copy it exactly, yet the most accurate delineations will bear a greater resemblance to the most careless, than the careless ones will bear to one another.

Adam Smith, The Theory of Moral Sentiments [S1759]

We used examples to explain the concepts of subtyping, reference, and composition relationships. Of course, this approach is not new at all. Lewis Carroll in his Alice books (and elsewhere) used many examples in explaining important mathematical and logical concepts to children. These examples were crisp, clear, and representative of the concepts illustrated there.

As a familiar example³³ of business patterns (both basic and more specific), consider Lewis Carroll's Court of Justice [C1865].

The King and Queen of Hearts were seated on their throne when they arrived, with a great crowd assembled about them—all sorts of little birds and beasts, as well as the whole pack of cards: the Knave was standing before them, in chains, with a soldier on each side to guard him; and near the King was the White Rabbit, with a trumpet in one hand, and a scroll of parchment in the other. In the very middle of the court was a table, with a large dish of tarts upon it ...

Alice had never been in a court of justice before, but she had read about them in books, and she was quite pleased to find that she knew the name of nearly everything there, "That's the judge," she said to herself, "because of his great wig." ...

"And that's the jury box," thought Alice; "and those twelve creatures" (she was obliged to say "creatures," you see, because some of them were animals, and some were birds,) "I suppose they are the jurors."

We see here how and why (the business pattern of) subtyping was used when Alice had to use the term creatures (Carroll does not introduce the name of the subtyping concept, but clearly introduces the concept itself) and also how the business pattern of a court was used in a very explicit manner. Indeed, Alice had read about that pattern in books (because she knew the name of nearly everything there, she successfully recognized the structure of the pattern and its formal parameters), and the rather unusual actualization of parameters needed to instantiate the pattern presented no problems whatsoever for Alice!

Here is a fragment of this business specification represented in UML (extended with precise specifications of generic relationships, see Appendices A and B): We will not go into the details here; just note that ?assembly? denotes a composition in which components must exist in order for their composite to be able to exist.

Figure 5

Thus, a (somewhat) unusual example may be considered as a good choice of a representative one. Such a choice encourages thinking, and explicit reasoning about the example and the underlying concepts helps to infer these concepts, anticipate changes and determine the commonalities between various situations. As a result, we root out general underlying concepts (and assumptions). We see an abundance of such beautiful unusual examples in Carroll's books.

At the same time, the example above is not a specification of subtyping or composition, and neither is it a specification of a court of justice. It is a specification of a very particular court of justice described in the fragment of Lewis Carroll's Alice in Wonderland. Nevertheless, a general specification may be inferred—and then validated!—from a set of suitably chosen representative examples. We should take into account that any example presents much more specific information than necessary for a specification and thus makes it much more difficult to separate the essential from the accidental. This characterizes the difference between the Aristotelian approach [BETA1992, KR1994] and a prototypical approach. The former provides for the intension of the (predicate of the) specification; the latter provides for a probably incomplete extension of the (predicate of the) specification. When we use the former, we can always find out whether a fact corresponds to the specification;³⁴ when we use the latter, we often cannot do that.³⁵ In other words, replacing a specification with an example, or with a set of examples, makes treatment of any facts not directly dealt with by these examples substantially more difficult: the user of examples has to guess.