|click here for POSD home page|
The structure of a very complex system cannot be represented in one diagram as such a diagram would be far too large and convoluted. The structure can only be represented by a hierarchy of diagrams with the top level diagrams representing the gross structure of the system and the bottom level ones representing its detailed structure. Different hierarchies are needed to represent different views of the purpose and structure of the system. Another part of this POSD presentation discusses this hierarchical structuring of systems in detail.
A complex business problem needs to be tackled at many levels spanning from the value-chain level, via organisation, process and software levels, to the hardware level. The structures of the systems at each of these levels need to be considered and represented with hierarchical structures (resulting in some of the many different hierarchical structures for the many different views referred to in the previous paragraph). Another part of this POSD presentation discusses this multi level structuring of systems.
The implication of the above is that any system (or process) engineering project needs to develop and manipulate many different representations of the structure of its systems. This is what is found in such projects. However one also observes the projects having great difficulty correlating their many different representations. Each representation seems reasonable in itself, but the relationship between the representations remains unclear, the entities in one representation cannot be correlated with the entities in another.
A hardware project has, at the lowest (most detailed) level, board layout diagrams that represent the component chips and their interconnections and, at the highest (most abstract and least detailed) level, abstract representations of the total hardware system, showing the major components of the system (processors, stores, devices, buses, etc.) and their interactions. Between these extremes the project has other diagrams representing the structure of parts of the system. All of the diagrams use rectangles to represent component systems and lines to represent interactions between components. However engineers on the project experience great difficulty relating the rectangles and lines in the lower level diagrams to those in the higher level ones.
A process re-engineering project has diagrams representing the structure of the process that is being re-engineered, diagrams representing the structure of the supporting software systems, and probably diagrams representing the structure of the underlying hardware networks and systems. Each of the diagrams is useful and meaningful but the project experiences problems determining how they relate to each other.
If one examines the diagrams used by hardware engineers one observes a curious feature. Each rectangle in the higher level diagrams expands into a network of thousands of chips and their interconnections in the lower level diagrams, but each line in the higher level diagrams corresponds to just a single interconnection or at best a set of such interconnections in the lower level diagrams. This means that hardware engineers are being forced by their design notations to identify and freeze low level interconnections (wires or etchings) between major components early in their design process (in high level diagrams) thus creating bottlenecks within their designs. This phenomena has been referred to as the wire syndrome, engineers are constrained to think of lines as wires rather than more complex interaction mechanisms.
A similar phenomena can be observed in modern process re-engineering projects. The declared aim of such a project is to radically change the way an organisation operates and the way it interacts with the public. One would therefore expect to observe the project engineers examining the major interactions between the organisation's professionals and with the public and deciding how these interactions should be changed or replaced. Instead one observes the engineers discussing the different types of document produced, how these documents should be moved between floors and buildings, and what the post room and clerical assistants should do with the documents. This happens because document movements are the only interactions that are allowed (by the process design notation) in the high level representations of the business process. The notations do not allow more complex interactions to be represented. The wire syndrome has reappeared in a business process re-engineering context as a document-flow syndrome.
In both examples the notations allow the rectangles in high level diagrams to represent very powerful abstractions (implemented by networks of rectangles and lines in lower level diagrams) whilst restricting the lines to weak abstractions (at best sets of lines in lower level diagrams). The notations force a mismatch between the abstractions represented by rectangles and those represented by lines.
Other parts (referred to above) of this POSD presentation demonstrate that a number of hierarchical structures may be required to represent the structure of even the simplest system, and that the hierarchical structures required vary from system to system according to the structural views that are important for that system.
The different hierarchies meet at the "top" in the sense that they all represent the structure of the same system or parts thereof. They meet at the "bottom" in the sense that they all represent the system as being built from the same very basic building blocks. Even though this top and bottom notionally exist, for a complex design problem it is impossible to reach either, the top embraces every possible view of the system and its environment, and the bottom encompasses a myriad of detailed building blocks. The task of the designer is to work "middle-out" in this vast hierarchical structure, correlating the entities found in the various branches of the structure.
At the computer programming level this manifests itself in the "structure clash" problem when the programmer has to structure a program to match one of many possible hierarchical structures and then finds the program handling the other structures awkwardly. This structure clash problem arises because programming languages are usually only capable of satisfactorily representing one structural view at a time. This might be acceptable for programming languages but is not acceptable for design notations. Design notations need to be able to represent and correlate many structural views.
The mistake made by most design methods is to assume that this vast hierarchical structure is a tree structure or a small number of stylised tree structures (data, activity, type, etc.). These methods restrict the ability of designers to adequately represent the structure of systems. As Michael Jackson says, "hierarchical structure is the sand on which Top-Down methods are built".
The above has identified three major problems with existing notations for representing the structure of systems:
The definition and examples of POSD show how POSD overcomes these problems.
last revision: 21st June 1997