Semantics of (Business) Specifications: Relating Business Needs to IT

Business specifications have been used for centuries and perhaps millennia to understand and describe businesses independently of their possible realization. This understanding often has been expressed in a simple, clear, precise, and explicit way, so that irrelevant details (e.g., possible solutions) were suppressed. However, the current situation in IT development appears to be less than ideal: 85% of IT departments in the US fail to meet their organizations’ strategic business needs (ComputerWorld, October 11, 1999). Often, these business needs were — if described at all — shown in lengthy unstructured narratives or box-and-line diagrams. What is wrong with these approaches? When businesses were small or relatively simple, and when it was possible to rely on intervention of human subject matter experts at all stages of a business, and especially in non-standard situations, it was possible to treat the realization of business objectives as a craft or a kind of a magic. In some cases, however, simple businesses worked well [1]: “The only trades which it seems possible for a joint stock company to carry on successfully without an exclusive privilege are those of which all the operations are capable of being reduced to what is called a Routine, or to such a uniformity of method as admits of little or no variation. Of this kind is, first, the banking trade; secondly, the trade of insurance from fire, and from sea risk and capture in time of war; thirdly, the trade of making and maintaining a navigable cut or canal; and, fourthly, the similar trade of bringing water for the supply of a great city.” This Routine became routine by being precisely specified and being teachable in an explicit manner, without the need for the pupil (or student) to spend “seven meagre years” (E.W.Dijkstra) to observe and absorb by osmosis the magic done by the Master. Many businesses now are not as simple, and those that still are, want to get a competitive advantage by becoming more flexible — often by dealing with less standard situations. Precise specifications of these less standard businesses or aspects of a business is essential for success. Clearly, if a part of a business is to be realized by a computer-based IT system, this specification is essential for the specifiers and developers of such a system. And if such a business specification does not exist or is inadequate then the solution provided by the IT system will be — at best — a solution of a different problem. This different problem may be of no interest whatsoever to the customers of the business [2]: “The entrepreneur’s technological ability does not affect the specific entrepreneurial profit or loss.... The technologically more efficient entrepreneur earns higher wage rates or quasi-wage rates than the less efficient in the same way in which the more efficient worker earns more than the less efficient. The more efficient machine and the more fertile soil produce higher physical returns per unit of costs expended.... But the specific entrepreneurial profits and losses are not produced by the quantity of physical output. They depend on the adjustment of output to the most urgent wants of the consumers. What produces them is the extent to which the entrepreneur has succeeded or failed in anticipating the future — necessary uncertain — state of the market.” This is where the 85% comes from. We, the (IT) analysts, specifiers, designers and developers, can do better than that and bring much more rigor to the world of commercial development. We should not forget that analyzing something means making explicit its parts and relationships between them,; this results in dissolution of ill-conceived problems, clear restatement of ill-posed problems, disclosure of presuppositions, elucidation, definition, deduction, and much more [3]. Concepts and constructs for analysis and proper handling of business — and any other — specifications exist, and some of them have been formalized in various international standardization activities such as the ISO Reference Model of Open Distributed Processing (RM-ODP). They have been around in programming for a while, since at least the mid-1960s when they were formulated by EW.Dijkstra and others, with the goal of achieving intellectual manageability. The most important among them are the need for abstraction and precision in dealing with complex systems of any kind. This need has been understood by Adam Smith more than two centuries ago, and more recently by F.A.Hayek who said that the central problem of his life was the formation and recognition of