- The Case for a New Business Model
Software is not a product. It is a medium to store knowledge.
The Five Media of Knowledge
Knowledge in each medium has different levels of
- DNA - DNA was first knowledge
storage medium. It is a set of Turing machine instructions on how to
- Brains - We use our brains as a place to store
and restore knowledge
- Hardware - Hardware is a tool that
Humans makes to store knowledge.
- Books - Books made
knowledge portable through space and time.
- Software -
Software is the most recent knowledge storage medium. The value of
software is not the code, but what the code does.
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.
- persistency : how long knowledge stored will remain
speed: how quickly the knowledge can be changed
how much the knowledge storage and change can be done deliberately
how knowledge can be applied to action, how is its ability to affect
the outside work.
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.
- 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
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.
- 0th Order Ignorance (0OI) - Lack of Ignorance
0OI is knowledge. We know something and can demonstrate it in some
- 1th Order Ignorance (1OI) - Lack of Knowledge
1OI is the basic ignorance. We don't know something and can readily
identify that fact.
- 2th Order Ignorance (2OI) - Lack
We don't know that we don't know something. We are not only ignorant of
something, we are unaware of this fact.
- 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.
- 4th Order Ignorance (4OI) - Meta
We don't know about the five orders of ignorance
- 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
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.
We can only define software processes at two levels: too vague and too
Do not attempt to develop monolithic processes that try to define every
activity at every level.
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).
- The Case for a New Business Model, Phillip G. Armour,
Communications of the ACM August 2000
- The Five Orders of Ignorance, Phillip G. Armour, Communications
of the ACM October 2000
- The Laws of Software Process, Phillip G. Armour, Communications
of the ACM January 2001