Conceptual Commonalities in Modeling of Business and IT Artifacts

Background

Creating business and IT system models readable and understandable to all stakeholders is possible only if the system of concepts underlying such models is well-defined, understandable to the model readers, and does not require extensive and painstaking explanations. Because the experiences of different stakeholders are usually quite different, the fundamental underlying concepts should be invariant with respect to the specific business (or IT) domain of interest.

Fortunately, a system of simple and elegant abstract modeling concepts and constructs exists and has been stable for centuries. Precise definitions of its semantics come from exact philosophy, mathematics, programming, and systems thinking. It has been successfully used in theory, in industrial practice (including international standards such as the Reference Model of Open Distributed Processing (ISO/IEC, 1995)), and in teaching of business and IT modeling. It includes such generic concepts as system, model, abstraction, structure, relationship, invariant, state, action, behavior, conformance, type, composition, template, name in context, and so forth, thus providing a solid foundation for systems of appropriate domain-specific concepts, such as contract, trade, confirmation, derivatives, options trade, and so forth, for the financial domain.

Why are we reusing concepts from exact philosophy? As Mario Bunge observed, “all factual sciences, whether natural, social, or mixed, share a number of philosophical concepts…and a number of philosophical principles” (Bunge, 2001). Moreover, philosophers “won’t remain satisfied with examples [...]; they will seek general patterns” (Bunge, 2004). The work of such outstanding systems thinkers as Mario Bunge and F.A. Hayek includes clear and concise definitions and descriptions of such concepts and of some fundamental patterns which are essentially the same as those formulated—independently—in the best IT-based sources. Specifically, the concept of a relation is indispensable for understanding a system:” so long as the elements... are capable of acting upon each other in the manner determining the structure of the machine, their other properties are irrelevant for our understanding of the machine” (Hayek, 1952), and “the structure of a system is the set of all the relations among its components, particularly those that hold the system together” (Bunge, 2003). The same kinds of generic relations hold together very different systems, thus providing a solid foundation for bridging the communication gap between business and IT experts.

E.W. Dijkstra observed decades ago (Dijkstra, 2007) that “it is the sole purpose of the specifications to act as the interface between the system’s users and the system’s builders. The task of “making a thing satisfying our needs” as a single responsibility is split into two parts– “stating the properties of a thing, by virtue of which it would satisfy our needs” and “making a thing guaranteed to have the stated properties.” These considerations apply both to the “business side” and to the “IT side” of any application development (or purchase) project.