Tag Archives: Herbert Simon

Applying industrial engineering to information technology

This post is part of my collaborative research with Shinsei Bank on highly-evolvable enterprise software.  It is licensed under the Creative Commons Attribution-ShareAlike 3.0 license.  I am indebted to Shinsei Bank for supporting this research and to Jay Dvivedi for mentoring me in the art of enterprise systems.  All errors are my own.

The fourth edition of Herbert Simon’s Administrative Behavior contains a brief section titled “Applying information technology to organization design”.  In the industrial age, Simon says, organization theory was concerned mainly with how to organize for the efficient production of tangible goods.  Now, in our post-industrial society, problems of physical production have diminished in importance; the new challenge is how to organize for effective decision-making.  Simon characterizes the challenge as follows:

The major problems of organization today are not problems of departmentalization and coordination of operating units.  Instead, they are problems of organizing information storage and information processing–not division of labor, but factorization of decision-making.  These organizational problems are best attacked, at least to a first approximation, by examining the information system and the system of decisions it supports in abstraction from agency and department structure. (1997, 248-9)

In essence, Simon proposes that we view the organization as a system for storing and processing information–a sort of computer.  Extending the computer metaphor, organizations execute software in the form of routines (March and Simon call them performance programs).  Department structure, like the configuration of hardware components in a computer, has some relevance to the implementation of decision-making software, but software architects can generally develop algorithms without much concern for the underlying hardware.

Continue reading

Physical constraints on symbolic systems

This post is part of my collaborative research with Shinsei Bank on highly-evolvable enterprise software.  It is licensed under the Creative Commons Attribution-ShareAlike 3.0 license.  I am indebted to Jay Dvivedi and his team at Shinsei Bank for supporting this research.  All errors are my own.

One of Jay’s design rules to which he attaches great importance is physical separation of software modules (i.e., Contexts) and physical motion of information between them.  According to this rule, software modules should be installed on physically separated computers.

Yesterday, I had the opportunity to discuss Shinsei’s architecture with Peter Hart, an expert on artificial intelligence and the founder and chairman of Ricoh Innovations, Inc.  Peter was very intrigued by Jay’s use of design rules to impose physical constraints on software structure.  I’d like to acknowledge Peter’s contribution to my thinking by introducing his perspective on possible implications of such physical constraints.  Then, I’ll describe my follow-up conversation with Jay on the topic, and conclude with some of my own reflections.  Of course, while I wish to give all due credit to Peter and Jay for their ideas, responsibility for any errors rests entirely with me.

Peter’s perspective

Peter approached the issue from a project management perspective.  Why, he asked me, are software development projects so much more difficult to manage compared to other large-scale engineering projects, such as building a bridge or a factory? The most plausible explanation he has found, he told me, is that software has many more degrees of freedom.  In contrast to mechanical, chemical, civil, or industrial engineering, where the physical world imposes numerous and often highly restrictive constraints on the design process, there are hardly any physical constraints on the design of software.  The many degrees of freedom multiply complexity at every level of the system, and this combinatorial explosion of design parameters makes software design an enormously complex and extraordinarily difficult problem.

Thus, Peter suggested that artificial imposition of physical constraints similar to those found in other engineering domains could help bring complexity under control. These constraints might be designed to mimic constraints encountered when performing analogous physical tasks in the real world. There is a tradeoff, since these constraints close off large swathes of the design space; however, if the goal of the designer is to optimize maintainability or reliability while satisficing with respect to computational complexity, then perhaps the benefit of a smaller design space might outweigh possible performance losses.

Jay’s perspective

After my conversation with Peter, I asked Jay why he places so much importance on physical separation and physical movement.

To begin with, he said, it is difficult to create and enforce boundaries within a single computer.  Even if the boundaries are established in principle, developers with “superman syndrome” will work around them in order to “improve” the system, and these boundary violations will be difficult to detect.

Work is made easier by keeping related information together and manipulating it in isolation.  Jay uses the analogy of a clean workbench stocked with only the necessary tools for a single task.  Parts for a single assembly are delivered to the workbench, the worker assembles the parts, and the assembly is shipped off to the next workstation.  There is never any confusion about which parts go into which assembly, or which tool should be used. Computer hardware and network bandwidth can be tuned to the specific task performed at the workstation.

Achieving this isolation requires physical movement of information into and out of the workstation.  Although this could be achieved, in theory, by passing data from one module to another on a single computer, designers will be tempted to violate the module boundaries, reaching out and working on information piled up in a motionless heap (e.g., shared memory or a traditional database) instead of physically moving information into and out of the module’s workspace.

When modules are physically separated, it becomes straightforward to reconfigure modules or insert new ones, because flows of information can be rerouted without modifying the internal structures of the modules. Similarly, processes can be replicated easily by sending the output of a workstation to multiple locations.

Finally, physical separation of modules increases system-level robustness by ensuring that there is no single point of failure, and by creating opportunities to intervene and correct problems.  Inside a single computer, processes are difficult to pause or examine while operating, but physical separation creates an interface where processes can be held or analyzed.

Concluding thoughts

The idea of contriving physical constraints for software systems seems counterintuitive.  After all, computer systems provide a way to manipulate symbols largely independent of physical constraints associated with adding machines, books, or stone tablets. The theory of computation rests on abstract, mathematical models of symbol manipulation in which physical constraints play no part.  What benefit could result from voluntarily limiting the design space?

Part of the answer is merely that a smaller design space takes less time to search.  Perhaps, to echo Peter’s comment, software development projects are difficult to manage because developers get lost in massive search spaces.  Since many design decisions are tightly interdependent, the design space will generally be very rugged (i.e., a small change in a parameter may cause a dramatic change in performance), implying that a seemingly promising path may suddenly turn out to be disastrous1.  If physical constrains can herd developers into relatively flatter parts of the design space landscape, intermediate results may provide more meaningful signals and development may become more predictable.  Of course, the fewer the interdependencies, the flatter (generally speaking) the landscape, so physical separation may provide a way to fence off the more treacherous areas.

Another part of the answer may have to do with the multiplicity of performance criteria.  As Peter mentioned, designers must choose where to optimize and where to satisfice.  The problem is that performance criteria are not all equally obvious.  Some, such as implementation cost or computational complexity, become evident relatively early in the development process.  Others, such as modularity, reliability, maintainability, and evolvability, may remain obscure even after deployment, perhaps for many years.

Developers, software vendors, and most customers will tend to be relatively more concerned about those criteria that directly and immediately affect their quarterly results, annual performance reviews, and quality of life.  Thus, software projects will tend to veer into those areas of the design space with obvious short-term benefits and obscure long-term costs.  In many cases, especially in large and complex systems, these design tradeoffs will not be visible to senior managers.  Therefore, easily verifiable physical constraints may be a valuable project management technology if they guarantee satisfactory performance on criteria likely to be sacrificed by opportunistic participants.

Finally, it is interesting to note that Simon, in The Sciences of the Artificial, emphasizes the physicality of computation in his discussion of physical symbol systems:

Symbol systems are called “physical” to remind the reader that they exist as real-world devices, fabricated of glass and metal (computers) or flesh and blood (brains).  In the past we have been more accustomed to thinking of the symbol systems of mathematics and logic as abstract and disembodied, leaving out of account the paper and pencil and human minds that were required actually to bring them to life.  Computers have transported symbol systems from the platonic heaven of ideas to the empirical world of actual processes carried out by machines or brains, or by the two of them working together. (22-23)

Indeed, Simon spent much of his career exploring the implications of physical constraints on human computation for social systems.  Perhaps it would be no surprise, then, if the design of physical constraints on electronic computer systems (or the hybrid human-computer systems known as modern organizations) turns out to have profound implications for their behavioral properties.

1 When performance depends on the values of a set of parameters, the search for a set of parameter values that yields high performance can be modeled as an attempt to find peaks in a landscape the dimensions of which are defined by the parameters of interest.  In general, the more interdependent the parameters, the more rugged the landscape (rugged landscapes being characterized by large numbers of peaks and troughs in close proximity to each other).  For details, see the literature on NK models such as Levinthal (1997) or Rivkin (2000).

Contexts as elementary subsystems

This post is part of my collaborative research with Shinsei Bank on highly-evolvable enterprise architectures.  It is licensed under the Creative Commons Attribution-ShareAlike 3.0 license.  I am indebted to Jay Dvivedi and his team at Shinsei Bank for sharing with me the ideas developed here.  All errors are my own.

Contexts are the elementary building blocks in Jay’s system architecture.  I’ll define Contexts precisely below, but let me begin with a passage from The Sciences of the Artificial that provides a frame for the discussion.

By a hierarchic system, or hierarchy, I mean a system that is composed of interrelated subsystems, each of the latter being in turn hierarchic in structure until we reach some lowest level of elementary subsystem.  In most systems in nature it is somewhat arbitrary as to where we leave off the partitioning and what subsystems we take as elementary.  Physics makes much use of the concept of “elementary particle,” although particles have a disconcerting tendency not to remain elementary very long.  Only a couple of generations ago the atoms themselves were elementary particles; today to the nuclear physicist they are complex systems.  For certain purposes of astronomy whole stars, or even galaxies, can be regarded as elementary subsystems.  In one kind of biological research a cell may be treated as an elementary subsystem; in another, a protein molecule; in still another, an amino acid residue.

Just why a scientist has a right to treat as elementary a subsystem that is in fact exceedingly complex is one of the questions we shall take up.  For the moment we shall accept the fact that scientists do this all the time and that, if they are careful scientists, they usually get away with it. (Simon, 1996, 184-5)

For Jay, the Context is the elementary subsystem.  Like an atom, the Context is in fact a complex system; however, designed properly, the internal structure of the Context is invisible beyond its boundary.  Thus, system architects can treat the Context as an elementary particle that behaves according to relatively simple rules.

What is a Context?

A Context is a logical space designed to facilitate the performance of a small, well-defined set of actions by people acting in a small, well-defined set of roles.  Metaphorically, Contexts are rooms in a house: each room is designed to accommodate certain actions such as cooking, bathing, sleeping, or dining. Contexts exist to provide environments for action.  Although Contexts bear some resemblance to functions or objects in software programs, they behave according to substantially different design rules (see below).

Defining the Context as the elemental subsystem enables us, by extension, to define the elemental operation: a person, in a role, enters a Context, performs an action, and leaves the Context.  All system behavior can be decomposed into these elemental operations, I’ll label them Interacts for convenience, where a person in a role enters, interacts with, and leaves a Context.  The tasks performed by individual Interacts are very simple, but Interacts can be daisy-chained together to yield sophisticated behavior.

Design rules for Contexts

Creating Contexts that can be treated as elementary subsystems requires adhering to a set of design rules.  Below, I describe some of the design rules that have surfaced in my conversations with Jay.  These rules may not all be strictly necessary, and they are probably not sufficient; refining these design rules will likely be an essential part of developing a highly-evolvable enterprise software architecture based on Jay’s development methodology.

  1. Don’t misuse the context. Only allow those actions to occur in a Context that it was designed to handle; do not cook in the toilet or live in the warehouse, even if it is possible to do so.  Similarly, maintain the integrity of roles: allow a person to perform only those actions appropriate to his or her role.  The repairman should not cook; guests should not open desk drawers in the study.
  2. Physically separate contexts. Locate Contexts on different machines.  Never share a databases among multiple contexts.
  3. Only Interacts connect a Context to the rest of the system. Data enter and leave a context only through Interacts, carried in or out by a person in a role.
  4. There is no central database. Every Context maintains its own database or databases as necessary.
  5. Each Context permits only a limited set of simple, closely related actions. Contexts should be like a European or Japanese house where the toilet, bath, and washbasin are in separate rooms, rather than like a US house where all three are merged into a single room.  If a Context must handle multiple modes of operation or multiple patterns of action, it should be decomposed into multiple Contexts.
  6. Avoid building new Contexts. If a required behavior does not appear to fit in any existing Contexts, decompose it further and look for sub-behaviors that fit existing Contexts. Build new Contexts only after thorough decomposition and careful consideration.
  7. Only bring those items–those data–into the Context that are required to perform the task at hand.
  8. Control entry to the Context. Ensure that only appropriate people, in appropriate roles, with appropriate baggage (data) and appropriate intentions can enter.
  9. Log every Interact from the perspective of the person and the Context. The person logs that he or she performed the action in the Context, while the Context logs that the action was performed in the Context by the person.  This creates mutually verifying dualism.

Why bother?

The purpose of establishing the Context as an elementary subsystem is to simplify the task of system design and modification.  As Simon points out, “The fact that many complex systems have a nearly decomposable [i.e., modular], hierarchic structure is a major facilitating factor enabling us to understand, describe, and even “see” such systems and their parts.” (1996, 207) Establishing the Context as an elementary subsystem in enterprise software is a technique for rendering enterprise software visible, analyzable, and comprehensible.

Bounding and restricting the Context vastly simplifies the work of implementors, enabling them to focus on handling a small family of simple, essentially similar actions.  The Context can be specialized to these actions, thereby reducing errors and  increasing efficiency.

Contexts hide the complexity associated with data and problem representations, databases, programming languages, and development methodologies, enabling system architects to focus on higher-level problems.  In discussions with Jay, he almost never mentions hardware, software, or network technologies, since he can generally solve design problems without considering the internal structures of his Contexts and Interacts.

Since myriad organizational processes are assembled from a relatively small library of simple actions combined in different ways, systems that support these processes exhibit similar redundancy.  Thus, Contexts designed to handle very simple actions can be reused widely, decreasing the cost and time required to develop new systems.

Finally, it is possible that Contexts, by explicitly associating people and roles with all actions, may help clarify accountability as organizational action develops into an increasingly complex mixture of human and computer decision-making.

Concluding thoughts

In essence, Contexts and Interacts are artificial constructs intended to allow high-level system design problems to be solved independently of low-level implementation problems.  The extent to which the constructs achieve this goal depends on the effectiveness of the design rules governing the constructs’ behavior.  Positing Contexts and Interacts as the elementary subsystems in Jay’s development methodology establishes a theoretical structure for further inquiry, but neither guarantee their fitness for this purpose nor implies the impossibility of other, perhaps more effective elementary subsystem constructs.

On several occasions, I’ve been asked how this approach differs from service-oriented architectures.  I’ll explore this question in a subsequent post.

Knowledge: A Short Essay and an Annotated Reading List

One of my colleagues asked me what to read to learn about knowledge. The answer requires a bit of explanation.

There are two approaches to knowledge. On one hand, there are the epistemologists. The epistemologists have spent many centuries developing criteria for evaluating whether a belief qualifies as knowledge. On the other hand, there are the computer scientists and organization theorists, who tend to focus on how knowledge affects the performance of problem solving systems (i.e., humans, computers, organizations). These two approaches can be reconciled as follows.

For the computer scientists and organization theorists, knowledge is anything that improves the performance of a problem solving system, except for information processing capacity. If two systems execute the same number of symbolic operations but one system gets a better answer, it must know something the other system doesn’t.

Epistemologists, by contrast, want perfect knowledge that will never lead a problem solving system to act in ways that betray its own goals. Such perfect knowledge is difficult to obtain, and perhaps even more difficult to define. After a few millennia, epistemologists still haven’t come up with a satisfactory definition. This is not to say that the field has failed: epistemology can help us evaluate the quality of knowledge and acquire better knowledge.

A short example may help clarify the matter. To a computer scientist, “what goes up, must come down” is a reasonably good piece of knowledge. It tells a problem solving system not to throw a water balloon straight up in the air. To an epistemologist, this isn’t knowledge at all, because it isn’t true. If I launch a rocket into space, it doesn’t need to come down. In fact, up and down are not even valid except within very limited frames of reference. The computer scientist has a tolerant, inclusive philosophy of knowledge, while epistemologists have an exacting, exclusive philosophy of knowledge.

For those of us concerned with understanding the performance of problem solving systems, the problems raised by epistemologists are not of primary importance.We are better served with an inclusive definition of knowledge that asks not whether the knowledge is true, but whether it is useful. Those interested in this view of knowledge may find the following books and articles useful.

How organizations represent and exploit knowledge

March, J. G. and H. A. Simon. Organizations. 2nd ed. Cambridge, MA: Blackwell, 1993.

Simon, H. A. The Sciences of the Artificial. 2d ed. Cambridge, MA: MIT P, 1981.

Organizations and The Sciences of the Artificial are essential introductions to the science of problem solving systems (equivalently, symbol systems or information processing systems). Chapters 6 and 7 of Organizations are especially important, because they describe the functioning of performance programs (equivalently, routines), which are one of the most important ways that problem solving systems represent knowledge. Make sure to get the second edition, which has useful commentary after each chapter. Read these books several times.

How organizations learn

Mukherjee, A. S. and R. Jaikumar. “Managing Organizational Learning: Problem Solving Modes Used on the Shop Floor.” 1992.

Bohn, R. and R. Jaikumar. “The Structure of Technological Knowledge in Manufacturing.” Working paper. 1992.

Clark, K. B., R. Henderson, and R. Jaikumar. “A Perspective on Computer Integrated Manufacturing Tools.” Boston, MA, 1988.

Jaikumar had a wonderfully precise grasp of how knowledge, learning, and problem solving interact and drive system performance. The first paper describes the mechanics of unstructured problem solving, which is closely related to learning. The second paper demonstrates how theoretical models can be used to investigate the way knowledge functions. The third paper sheds light on how computers influence learning. Although the studies focus on manufacturing, the principles generalize. Unfortunately, these excellent papers are not easily available

Darr, E. D., L. Argote, and D. Epple. “The Acquisition, Transfer, and Depreciation of Knowledge in Service Organizations: Productivity in Franchises.” Management Science 41, no. 11 (1995): 1750-62.

Edward Feigenbaum often says that knowledge usually comes in thousands of grains of gold dust rather than in large nuggets. This elegant empirical study beautifully captures this aspect of organizational knowledge, and provides an example of one technique for quantitatively analyzing knowledge, learning, and knowledge decay.

Epistemological perspectives

Newell, A. “The Knowledge Level.” AI Magazine 2, no. 2 (1981): 1-20, 33.

Nonaka, I. “A Dynamic Theory of Organizational Knowledge Creation.” Organization Science 5, no. 1 (1994): 14-37.

Lenat, D. B. and E. A. Feigenbaum. “On the thresholds of knowledge.” Artificial Intelligence 47, no. 1-3 (January 1991): 185 – 250.

These three articles by leading experts on problem solving and knowledge provide theoretical foundations for the inclusive, computer science/organization theory approach to knowledge. None provides a complete theory, but when read together they provide a great deal of insight. The significance of the ideas cannot be grasped without considerable reflection. It may help to read them repeatedly, perhaps interspersed with the other readings on the list.

Mechanics of knowledge systems

Davis, R, H. Shrobe and P. Szolovitz. “What Is a Knowledge Representation.” AI Magazine, Spring (1993), 17-33.

Feigenbaum, E. A., B. G. Buchanan, and J. Lederberg. “On Generality and Problem Solving: A Case Study Using the DENDRAL Program.” In Machine Intelligence, edited by B. Meltzer and D. Michie, 165-90: Edinburgh UP, 1971.

Feigenbaum, E. A. “Knowledge Engineering: The Applied Side of Artificial Intelligence.” Proc. of a symposium on Computer culture: the scientific, intellectual, and social impact of the computer. New York Academy of Sciences, 1984.

To understand the mechanics of knowledge, one must dig into questions of representation and inference. Davis’s article provides a useful overview of the issues involved in representation. Feigenbaum’s articles on DENDRAL and knowledge engineering describe the nuts and bolts of working with knowledge.

Simon on routinization

A great deal of organization theory literature distinguishes between routine and nonroutine activity.  Routine activity is programmed, while nonroutine activity is ad hoc.  But is any activity really unprogrammed?  As usual, Simon has the answer:

In what sense, then, can we say that the response of a system to a situation is nonprogramed? Surely something determines the response.  That something, that collection of rules of a procedure, is by definition a program.  By nonprogramed I mean a response where the system has no specific procedures to deal with a situation like the one at hand, but must fall back on whatever general capacity it has for intelligent, adaptive, problem-oriented action. (Herbert A. Simon, The New Science of Management Decision, 1977 p. 47)

In a strict sense, all organizational behavior is programmed, hence routinized.  Seemingly nonroutine activity (ad hoc problem solving, improvising) simply involves less specialized routines.  As organizations learn, they develop more specialized routines.