Why Use Business Modeling?
- Success and Failure of Projects and Strategies
- Core Competencies
- Education
- The Need for Understanding: Abstraction, Precision, Explicitness
- Abstraction: The Way to Put Management in Control
- Basic Structuring Constructs
- Business Rules: Precision vs. Handwaving
- Tacit Assumptions and "Evident Truths"
- Specifying Problems and Solutions
- Where to Start and Why: Business Domains
This chapter is from the book
This chapter is from the book
This chapter is from the book
Models are created and used for understanding. To achieve that, the modelers together with the stakeholders pick and choose those things, actions, and relationships among them that are of interest to the stakeholders. A model includes only the essential characteristics of the modeled world (sometimes also known as the Universe of Discourse1) and suppresses everything else. These essential characteristics are formulated using a small set of concepts, and in this manner, the original, often very complicated, situation is translated into its substantially simplified model. (There may be several models of the same situation depending upon the viewpoint, i.e., depending upon which characteristics are considered essential—and which are considered unimportant—by the holders of the viewpoint.)
The essential "business rules" of the modeled situation are formulated as properties of the constructs used in the model. Laws of elementary geometry or elementary physics are well-known examples presented in school; these laws are very widely and successfully used because they and their logical consequences govern models that accord well with experience. I show in this book that in business (and IT) models the laws are formulated as invariants of the relationships of the model as well as pre- and postconditions of actions of the model.
In the process (and as the result) of effective modeling, we observe that many constructs used in very different business and IT situations are the same, so that we can freely reuse these constructs and get their essential properties, instead of rediscovering these properties for each particular situation. Specifically, we note that an information management system technologically supported by modern computers and an information management system technologically supported by pencil and paper have many essential commonalities, and that, from the business viewpoint, the specifics of the technological virtual machine may be of no interest at all. Thus, the purpose of modeling is not to facilitate the usage of computer-based information management systems. (At the same time, some technological virtual machines may provide new business opportunities in the same manner as, for example, railroads did in the mid-19th century.)
We can reason about a simplified model of a very complex situation much more easily than we can reason about the situation itself. In other words, models help us to manage complexity and, therefore, to make substantiated decisions based on the well-understood and explicitly formulated essentials of the modeled situation. This is why most engineering or business artefacts—such as buildings, bridges, airplanes, enterprises, and markets—do not fall apart. The work of a modeler is analogous to the work of a physicist who "is trying to correlate the incoherent body of crude fact confronting him with some definite and orderly scheme of abstract relations, the kind of scheme he can borrow only from mathematics" [H1940]. The specifics of the mathematics used by a business or IT system modeler may differ from the specifics of the mathematics used by a physicist, but the essence—the structure—remains the same: mathematics is "the art and science of effective reasoning" (E.W. Dijkstra), where "effective" means "reduced to a doable amount" [D1976a]. Mathematics provides the patterns of thinking essential for managing complexity,2 and the ability to use mathematics is "one of the things that distinguishes professional engineers from technicians" [P2001]. I describe and use these patterns throughout the book. I apply the generic patterns to handle (discover, distill, reuse) business-specific patterns.
Creating good models is not easy;3 using these models and reasoning about them is much easier. At the same time, the process of modeling is not less valuable than its result, when we model a business, we get insights into its essentials. A good model of a business serves as a framework for making decisions about possible further directions of that business (including business process change), as well as about possible usage (and non-usage) of computer-based information technology systems in order to improve some characteristics of that business. These information technology systems also need to be well-understood, and in order to do that, they also have to be modeled.
In essence, good models provide for clear and explicit treatment of complicated problems.
Success and Failure of Projects and Strategies
A specification should, above all things, be orderly in arrangement, precise in diction, full and complete in all respects, and without repetition, excess of description, or elaboration of verbiage.
Specification for architects, surveyors and engineers [S1904]
We treat business modeling—following Dines Bjorner and others—as an essential part of software engineering. Mastery of software engineering concepts is one of the most important prerequisites for the success of an information management project.
It is very instructive to recall how the term "software engineering" first appeared. The NATO Science Committee established its Study Group on Computer Science in Autumn 1967, and this Study Group recommended a working conference on Software Engineering. This first Software Engineering working conference was held in Garmisch in 1968, resulting in a superb 230-page Proceedings volume [SE1969]. The Editors emphasized that "[t]he phrase 'software engineering' was deliberately chosen as being provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines, that are traditional in the established branches of engineering." The all-too-familiar term "software crisis" was introduced at that conference. The very useful discussions at the conference were related to the state of affairs in that area, including reasons for this crisis and ways to solve it. Most—if not all—ideas, concepts, and observations presented at that conference and at its follow-up in 1969 are still valid.
The ideas and concepts presented at the 1968 software engineering conference and earlier, in papers by Dijkstra, Hoare, and others published in the early to mid-1960s, ought to be reused rather than continually reinvented. These concepts provide an excellent framework for assessing the fashionable "novelties."4 We are not there yet. We have encountered many successes and failures,5 but in general it is difficult to declare that our present-day software engineering activities are always, or even most of the time, based on the same kind of foundations as established engineering activities are. In this context, we observe that the well-known need to distinguish early between the essential and the ephemeral is required not only for modeling of existing systems. This need was considered mandatory for an IT project success by Niklaus Wirth—one of the pioneers of computing system design—in his Turing Award lecture [W1985].
This book does not analyze the reasons of such a state of affairs. Rather, it deals with the most important issue in engineering, information management, and business transformation projects—the issue of specifications essential for understanding both the existing situation and the artefacts (whether existing or to-be-created) that may change this situation. For building or changing a system, a specification is the document defining the subject matter of the contract between the customer and the system builder (or changer). Engineering projects cannot succeed without specifications. Even if a project is very simple, its specifications exist in the minds of the project participant(s) including the customer. If different project participants have different specifications in their minds, then such a project may fail; the deliverable—if any—differs from the intended specification of that deliverable.
As one of the consequences, it may be extremely counterproductive to use in our projects any technologies that were not clearly and explicitly specified (or those technologies the realization of which does not satisfy their specification). We will see later that an IT system specification is composed of a business specification and a technology infrastructure6 specification; and obviously, if the specification of one of the components is unclear, then the specification—and thus the realization—of the composite is likewise unclear.
Finally, specifications are essential for decision making of any kind—strategic, tactical, or operational.7 Strategic business decisions made without adequate specifications, for example, based on a "few beautiful graphics that were laughably called a business plan" [L2001], often lead to spectacular failures. When strategic decisions are not being executed and the reasons are unclear, you must look at how these decisions are supposed to be realized within the explicitly specified organizational infrastructure, that is, within the structures, systems, incentives, and operating principles that collectively constitute that infrastructure, in order to understand the problem.