Machine view of software has our focus on accident property and ignores the essential property in enterprise software. In contrast, in systems view, software is not a machine but a system that contains both essential property and accident property. Accordingly practitioners with a systems view apply both technological knowledge, the knowledge of software design to build accident property, and scientific knowledge, the knowledge of representing business concepts to build essential property, to the solution of creating value to the customer.
Machine view and system view are two worldviews of two different kinds of methodologies. The distinction of two kinds of methodology can be made as man-like creation vs. god-like creation. Man-like creation is to create higher-level principle but not the lower-level principle to fulfill desired function. The lower-level principle is given by God to be harnessed into desired operation. The making of a mousetrap, for example is man-like creation. A mousetrap has several parts – platform, spring, catch, hammer, and hold-down bar – and all of them have to be in place for the trap to work. All these things created by people out of materials constrained by natural laws. These materials made of atoms and natural laws are not created by anyone. They are created by God and considered as given. In contrast, god-like creation would mean making materials and natural laws, making springs and everything out of the materials from scratch. God-like creation involves a single being creating something in its entirety, while man-like creation means creating something, but not its parts.
The making of enterprise software is god-like creation while the making of machines is man-like creation. God firstly created physics, the essence of matter, in its completion and secondly created biology, the accidents of matter, in its completion. Similarly, the making of enterprise software is to create the essential property in its completion before creating the accidental property. Using man-like creation to create enterprise software is the fundamental root cause of software engineering theory and accordingly the single reason for all software failures. God-like creation methodology for enterprise software is the only way to end the process war and promises needed consensus of software process where enterprise software, like bridges, are normally built on-time, on-budget, and do not fall down.
Thursday, June 5, 2008
Essence and accidents of enterprise software
Fred Brooks, drew on an ancient philosophical tradition of distinguishing between “essential” and “accidental” properties to describe software. Essential properties are those properties that a thing must have to be that thing. A car must have an engine, wheels, and a transmission in order to be a car. A car might or might have a V8 or V6, an automatic or manual transmission. These are “accidental” properties that do not affect the basic car-ness of a car.
Brooks argued that the essence of software development consists of working out the specification and verification of a highly precise and richly detailed set of interlocking business concepts to be componentized into parts of a software system. What makes software development difficult is its essential complexity, to quantify and componentize business concepts into interrelated parts. These parts will be in the place of particulars in natural world, the business context of the software under development, constrained by “natural laws,” or business logic and business rules. The task involves not only in quantifying and componentizing business concepts but also in determining the lower principle in form of business logic and business rules that constrain these business components.
Representing these business components using a computer languages is an accidental property. Major gains have been being realized: the invention of high level languages, movement to interactive computing from batch processing, and development of powerful integrated environments, and newer technologies including Service Oriented Architecture and Business Process Management that make representing business components ever easier. But in terms of describing software’s essential property – systematic and disciplined practice to quantify and componentize business concepts and identify constraints to these business components, we fairly begin. It is not that there is a lack of research in understanding and representing business concepts in quantitative and systematic way, but it is more about awareness, the worldview of what software is.
Brooks argued that the essence of software development consists of working out the specification and verification of a highly precise and richly detailed set of interlocking business concepts to be componentized into parts of a software system. What makes software development difficult is its essential complexity, to quantify and componentize business concepts into interrelated parts. These parts will be in the place of particulars in natural world, the business context of the software under development, constrained by “natural laws,” or business logic and business rules. The task involves not only in quantifying and componentizing business concepts but also in determining the lower principle in form of business logic and business rules that constrain these business components.
Representing these business components using a computer languages is an accidental property. Major gains have been being realized: the invention of high level languages, movement to interactive computing from batch processing, and development of powerful integrated environments, and newer technologies including Service Oriented Architecture and Business Process Management that make representing business components ever easier. But in terms of describing software’s essential property – systematic and disciplined practice to quantify and componentize business concepts and identify constraints to these business components, we fairly begin. It is not that there is a lack of research in understanding and representing business concepts in quantitative and systematic way, but it is more about awareness, the worldview of what software is.
Can we engineer enterprise software as machines?
Software components, unlike the particulars found in nature, are not constrained by natural laws. That natural constraint, the lower-level principle that intrinsically limits the complexity and interdependency of design constituents, is what the design, the higher-level principle, relies on. The lack of those natural constraints and physical dimensions in software implies that solutions that make tangible material meet our expectations do not apply. It means that writing software as a design activity is fundamentally different from the design activity in conventional fields of engineering. Engineering activity is how engineers decipher problems within the set of constraints imposed by the medium in which they are working. Construction isn’t software because it is constrained by the mechanical properties of the materials. Electronics isn’t software because it is constrained by the electrical properties of the components. Mechanical engineering isn’t software. Chemical engineering isn’t software; medical practice isn’t software, etc., etc.
Because software, not being made of matter, has no law of inanimate nature to be harnessed by the principle of design, software engineers, trained with knowledge of design (e.g. information engineering), do not have the scientific knowledge that design knowledge relies on. As such, software engineers design “bridges” without the knowledge of “material mechanics.” Accordingly, what we have is an enterprise software system whose principle of design, which supplies the defining functions, has no foundation to rely on. Either that, or the understanding of this foundation is not made deliberately explicit and remains in the background. As a result, solutions created by using the higher principle only work for conventional engineering, and do not work for software. Because of the lack of lower constraint in software, there is no tangible solution equivalent to conventional engineering in software. Accordingly the working of software tends to be arbitrary rather than anticipated by the theory.
Because of lack of complexity limiting natural constraints, if left otherwise unchecked, software will tend to expand arbitrarily, towards the only constraint left—the capacity of our brains. Arbitrary personal opinions, instead of practices guided by theory (such as the theory of harnessing lower-level principles), are what condition the outcome of software. This lack of objectivity (and accordingly, excess of arbitrary subjectivity) in software design activity is the central reason for practice and theory decoupling in software engineering. This lack of objectivity raises people’s expectations beyond all reason of what can and should be achieved within the project’s time and resource limitations. Given the fact that people are inconsistent in general, the practice of software engineering is more guesswork than disciplined inquiry. The desire to emulate engineering design to software is logically flawed and is the root cause of theory and practice decoupling in today’s software engineering.
Because all machines operate under the control of two distinct principles and if we want to design an operable machine, we must be explicit in our design on both level principles and how the higher-level principle harnesses the lower one. We should never, in principle, fail any traditional engineering design, whether it is a bridge, a vehicle or a building because we can in theory identify particulars at the lower level and construct higher level principle that harnesses the lower particulars precisely to fulfill defined functions. While today’s software systems are designed under one principle, the principle of design, without knowledge of lower level particulars and their governing laws. Therefore, we are confident to say that the lack of lower principle in software design makes software systems not operable. This insight points us a way forward to resolving the failure of software engineering, that is to construct and include lower principle into software. What is the lower level principle and what knowledge is required to construct such principle in enterprise software?
Because software, not being made of matter, has no law of inanimate nature to be harnessed by the principle of design, software engineers, trained with knowledge of design (e.g. information engineering), do not have the scientific knowledge that design knowledge relies on. As such, software engineers design “bridges” without the knowledge of “material mechanics.” Accordingly, what we have is an enterprise software system whose principle of design, which supplies the defining functions, has no foundation to rely on. Either that, or the understanding of this foundation is not made deliberately explicit and remains in the background. As a result, solutions created by using the higher principle only work for conventional engineering, and do not work for software. Because of the lack of lower constraint in software, there is no tangible solution equivalent to conventional engineering in software. Accordingly the working of software tends to be arbitrary rather than anticipated by the theory.
Because of lack of complexity limiting natural constraints, if left otherwise unchecked, software will tend to expand arbitrarily, towards the only constraint left—the capacity of our brains. Arbitrary personal opinions, instead of practices guided by theory (such as the theory of harnessing lower-level principles), are what condition the outcome of software. This lack of objectivity (and accordingly, excess of arbitrary subjectivity) in software design activity is the central reason for practice and theory decoupling in software engineering. This lack of objectivity raises people’s expectations beyond all reason of what can and should be achieved within the project’s time and resource limitations. Given the fact that people are inconsistent in general, the practice of software engineering is more guesswork than disciplined inquiry. The desire to emulate engineering design to software is logically flawed and is the root cause of theory and practice decoupling in today’s software engineering.
Because all machines operate under the control of two distinct principles and if we want to design an operable machine, we must be explicit in our design on both level principles and how the higher-level principle harnesses the lower one. We should never, in principle, fail any traditional engineering design, whether it is a bridge, a vehicle or a building because we can in theory identify particulars at the lower level and construct higher level principle that harnesses the lower particulars precisely to fulfill defined functions. While today’s software systems are designed under one principle, the principle of design, without knowledge of lower level particulars and their governing laws. Therefore, we are confident to say that the lack of lower principle in software design makes software systems not operable. This insight points us a way forward to resolving the failure of software engineering, that is to construct and include lower principle into software. What is the lower level principle and what knowledge is required to construct such principle in enterprise software?
How machine is engineered?
A machine is defined as an apparatus for applying mechanical power, consisting of a number of interrelated parts, each having a definite function. The manufacture of a machine consists of cutting suitably shaped parts and fitting them together so that their joint mechanical action should provide a required function. The structure of machines and the working of their structure are thus shaped by man, even while their material and the forces that operate them obey the laws of inanimate nature. In constructing a machine and supplying it with power, we harness the laws of nature at work in the machine’s material and its driving force, and make them serve our purpose. This harness is not unbreakable; the structure of the machine, and thus its working, can break down. But this will not affect the forces of inanimate nature on which the operation of the machine relied; it merely releases these forces from the restriction the machine imposed on them before it broke down.
Therefore the machine, as a whole, works under control of two distinct principles: the higher principle, the machine’s design and the lower principle, the law of inanimate nature on which the machine relies. Higher level properties are emergent in the sense that they are not reducible to the lower level principles. (For example, the shape of a cup is not reducible to the laws of physics.) The higher level harnesses the lower one, the lower level is the foundation and therefore independent of the level above. Hence, a machine is a system of dual control that relies, for the operations of its higher principle, on the working of the lower principle.
The higher-level relies for its operations on the level below and reduces the scope of the operation of the particulars at the level below by imposing on it a boundary that harnesses it to the service of the higher level. Because any machine operates under two levels of constraints, the design of machine therefore is to first identify the particulars of the lower level and its governing constraint and then synthesize the higher-level constraint, or ways of harnessing lower level particulars, to implement required functions.
The main task of engineers is to apply their scientific knowledge, the knowledge of lower-level principles to identify lower level particulars and their governing laws, and technological knowledge, the knowledge of higher-level principles or the knowledge of design to implement required functions, to the solution of technical problems. They then optimize these solutions within the requirements and constraints of the project. For example, electronic engineers apply circuit design knowledge to the electronic properties of materials to build circuits. Mechanical engineers apply mechanical design knowledge to the mechanical properties of different materials to build machines. Without a solid knowledge of the material mechanics, the lower level principle, we build bridges that cannot be accounted for.
Therefore the machine, as a whole, works under control of two distinct principles: the higher principle, the machine’s design and the lower principle, the law of inanimate nature on which the machine relies. Higher level properties are emergent in the sense that they are not reducible to the lower level principles. (For example, the shape of a cup is not reducible to the laws of physics.) The higher level harnesses the lower one, the lower level is the foundation and therefore independent of the level above. Hence, a machine is a system of dual control that relies, for the operations of its higher principle, on the working of the lower principle.
The higher-level relies for its operations on the level below and reduces the scope of the operation of the particulars at the level below by imposing on it a boundary that harnesses it to the service of the higher level. Because any machine operates under two levels of constraints, the design of machine therefore is to first identify the particulars of the lower level and its governing constraint and then synthesize the higher-level constraint, or ways of harnessing lower level particulars, to implement required functions.
The main task of engineers is to apply their scientific knowledge, the knowledge of lower-level principles to identify lower level particulars and their governing laws, and technological knowledge, the knowledge of higher-level principles or the knowledge of design to implement required functions, to the solution of technical problems. They then optimize these solutions within the requirements and constraints of the project. For example, electronic engineers apply circuit design knowledge to the electronic properties of materials to build circuits. Mechanical engineers apply mechanical design knowledge to the mechanical properties of different materials to build machines. Without a solid knowledge of the material mechanics, the lower level principle, we build bridges that cannot be accounted for.
Subscribe to:
Posts (Atom)