The Business of Software
  1. The Case for a New Business Model
  2. The Five Orders of Ignorance
  3. The Laws of Software Process
  4. Reference

The Business of Software is a fast column of the Communications of the ACM magazine. In three articles [1-3], Phillip G. Armour expressed in this column his interesting thinking about a new Business Model of Software. In his viewpoint, we have a wrong look at software, "Software is not treated as a medium, it is treated as a product, and this is the problem. The product is not the software, the product is the knowledge that goes into the software"
  1. The Case for a New Business Model
    Software is not a product. It is a medium to store knowledge.

    The Five Media of Knowledge

    1. DNA - DNA was first knowledge storage medium. It is a set of Turing machine instructions on how to create life.
    2. Brains - We use our brains as a place to store and restore knowledge
    3. Hardware - Hardware is a tool that Humans makes to store knowledge.
    4. Books - Books made knowledge portable through space and time.
    5. Software - Software is the most recent knowledge storage medium. The value of software is not the code, but what the code does.
    Knowledge in each medium has different levels of 
    1. persistency : how long knowledge stored will remain
    2. update speed: how quickly the knowledge can be changed
    3. intentionality: how much the knowledge storage and change can be done deliberately
    4. activeness: how knowledge can be applied to action, how is its ability to affect the outside work.
    Knowledge in software has all the above characteristics: it is persistent, quick to update, intentional, and most of all it is active. But we do not see software as a medium, but a product. The product focus is so strongly entrenched that it causes us to release software that does not contain the correct knowledge in the mistaken belief that we are shipping product.
    If software is not a product, then software development is not a product-producing activity - it is a knowledge-acquring activity. And a knowledge acquisition business  is very different from a product production business. It is easy to write code. In fact, we really don't spend time writing code or even building systems, we spend time trying to figure out what the systems should accomplish. And too often the activity of building a system is actually just the mechanism we use to acquire the knowledge.

  2. The Five Orders of Ignorance
    The problem arises when we think the code, rather than the knowledge in the code, is the product. Then we are tempted to ship the code as it is. If we views systems development as the acquisition of knowledge, we can also view it as the reduction or elimination of ignorance. We would hope that, at the end of the project, we are less ignorance than we are at the start.

    The Five Orders of Ignorance

    1. 0th Order Ignorance (0OI) - Lack of Ignorance
      0OI is knowledge. We know something and can demonstrate it in some tangible form
    2. 1th Order Ignorance (1OI) - Lack of Knowledge
      1OI is the basic ignorance. We don't know something and can readily identify that fact.
    3. 2th Order Ignorance (2OI) - Lack of Awareness
      We don't know that we don't know something. We are not only ignorant of something, we are unaware of this fact.
    4. 3th Order Ignorance (3OI) - Lack of Process
      We don't know of a way to find out there are things we don't know that we don't know.
    5. 4th Order Ignorance (4OI) - Meta Ignorance
      We don't know about the five orders of ignorance
    In System development, when we have 0OI, we have the answer to the problem. When we have 1OI, we have the question makes it fairly easy to find the answer. 2OI is the real problem. Not only do we not have the answer, we don't have even the question.This is where we start many projects. When we begin projects, we know, from experience there are many things we have to learn. We just don't know what they are. 3OI presents a real danger, we don't have a way to resolve my lack of knowledge during available time. Most of our work is to be the reduction of 2OI, and use of all software development methodologis as being 3OI processes. The application of 3OI to 2OI generates either 1OI or more rarely 0OI. The process either gives us the answer, or commonly, it gives us the question.

  3. The Laws of Software Process
    Why have some companies allocated enormous resources to defining a process for the construction of software?  Is the process bad? Is the process we use to define the process flawed? Should we not have process at all? or should we have more? Perhaps our problem isn't process, it's what we are asking process to do, and when and where we apply it.

    The Three Laws of Software Process

    1. Process only allows us to do things we already know how to to.
      Well-defined process only works for well-defined situations. We need to understand the inherent limitations of process and not expect it to do things it cannot do.
    2. We can only define software processes at two levels: too vague and too confining.
      Do not attempt to develop monolithic processes that try to define every activity at every level.
    3. The last type of knowledge to consider as a candidate for a implementation into an executable software form will be the knowledge of how to implement knowledge into an executable software form.
      Build and use systems that capture knowledge as it is discovered and make that knowledge available to others in a usable form. Automate, automate, automate ( but only where we know the process works).

  4. Reference
    1. The Case for a New Business Model, Phillip G. Armour, Communications of the ACM August 2000
    2. The Five Orders of Ignorance, Phillip G. Armour, Communications of the ACM October 2000
    3. The Laws of Software Process, Phillip G. Armour, Communications of the ACM January 2001