The proverbial communication gap between business and IT experts is mostly due to the fact that what is considered obvious to some business experts might not be obvious or even known to IT experts, and might substantially differ from what is considered obvious to other business experts. Thus, different stakeholders may understand the business domain and problems in tacit and quite different ways, and at the same time might be unaware of these differences. This leads to business-IT misalignment, and therefore to many serious information system failures, from life-threatening to financial or simply very annoying (loss of customers’ trust and patience). The article provides a concise overview of the topic, includes definitions of some essential concepts and constructs together with industrial examples of their use in modeling and in fostering business-IT alignment, and shows how a small subset of UML has been successfully used to represent the essential structure of a model.
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.
Key Terms in this Chapter
Type: A predicate ( ISO/IEC, 1995 ).
Generic Relationship: Composition, subtyping, or reference.
Analysis: “breaking down a whole into its components and their mutual relations” ( Bunge, 2003 ).
Relationship: A collection of items together with the invariant referring to the properties of the items.
Reference: A relationship between a reference and maintained items, such that some properties of the maintained item are determined by the properties of its reference item.
Subtyping: A relationship between a supertype and its subtypes, such that each instance of a subtype has all properties of its supertype and some additional—subtype-specific—properties.
Composition: A relationship between a composite and several components, such that some (emergent) properties of the composite are determined by the components and by the way they are combined.