Traditional information systems also tended to be linear. We started with a thorough set of requirements, from which we derived specifications which drove the programming. Programs were unit tested, system tested, and then delivered as a complete system. The system was then turned over to maintenance processing. These systems flowed from one stage to another, sometimes called the waterfall approach. Campbell (3) discusses linearity:
Perhaps Frederick Brooks summarized this most succinctly: "nine women can't make a baby in one month." (4) Countless information systems have been planned as the smooth, laminar flow of subprojects down the waterfall of systems implementation, only to discover turbulence, eddies, and erratic responses to small changes in requirements. These hallmarks of nonlinear systems are typically met with great dismay and generate a response of renewed efforts to force the system to a linear flow with greater levels of precision, adherence to the processes and structures which failed in the first place.
The "divide and conquer" linear thought process has assumed that one can decompose a system into pieces, program each piece, and then put them back together again to make a whole. But this is not the case with nonlinear systems. Just like Humpty Dumpty, things which are broken into pieces cannot necessarily be reassembled into a whole.
Another problem comes into play with hierarchical decomposition: point of view. The "hier" in hierarchical reflects the authoritative point of view from which the problem is decomposed. This point of view is typically a department manager, whose function is being automated by the computer. As all the departments in an organization are automated, these points of view are encrusted into "stovepipe" systems, each programmed to the needs of the departments. Eventually, there is an initiative to have an "integrated" system, which somehow interfaces all of these divergent points of view. Ironically, this is typically just another point of view, and adds to the confusion, rather than solving the problem. (5) One may as well try to pick up several fallen Humptys simultaneously.
An analogy to the problem might be to ask each of the department heads to create an outline of their organization’s behavior as they see it. The top left hand corner of each outline represents the point of view of the manager. Managers may start their outlines with the president, the customer, a product, a function, geographic location, chart of accounts, or other aspect of the organization. There is no right or wrong outline to their views; they are realistic representations of the world as they see it.
Now, suppose you were asked to "integrate" all these divergent outlines of the organization. "We are a single, integrated organization," you are told, and your job is to weed out the duplications and come up with the one true outline of the organization. You are faced with an impossible task. The organization from the point of view of the customer service representative is different from the point of view of the accountant. But if you try to put "customer service" and "accounting" as two subheadings under "company," you end up with much duplication. If you try to interleave the outlines, selecting sections from each, you become frustrated that you can't take things out of context from one outline and simply insert them into another. As the number of outlines (decomposition points of view) increases, the problem becomes geometrically more difficult. Yet this is the state of many of our corporate information systems today.
The information systems industry has been butting its head against this wall for 25 years, so much that it is now an ingrained behavior. So much so that experienced managers seek out the wall, place their head against it, and then complain about how hard it is to get any forward motion.