6.4 Information Structuring

6.4.1 The Problem Maze

In a large systems design project the number of functions and Problem Elements can be in the hundreds or even thousands, and the interactions among them can form a hyperspace with the complexity of the worldwide web. To intuitively follow your nose through this web is like being in a game of Dungeons and Dragons and stumbling into a maze with an empty pack, hence nothing to drop to find your way out. (This is a good analogy for all too many complex design projects.)

The information from the functional design analysis needs to be structured in a way that lends itself to design problem solving and synthesis. While the top-down hierarchy of functions constructed in the analytic phase helps to uncover design insights, it is inadequate as a strategic model for creative problem solving, because it does not lend itself to cross-categorical or lateral thinking. It would tend to bias the team toward inventing a component for each low-order function and to mechanically assemble them into something that might work, but like a Rube Goldberg contraption.

6.4.2 Mapping the Maze

The heart of the Structured Planning process (proposed in Alexander's Notes) involves using cluster analysis or decomposition programs to organize this information into a hierarchy of manageable subsets (clusters), producing a map for bottom-up solution generation and integration.

There are several variations on this method but all involve clustering descriptions of contexts and functions, real or potential problems to be resolved, and solution directives. Ultimately we are after an information structure that ties ensembles of these elements together, providing a well-ordered problem solving strategy.

The design team systematically determines the relationships among the Problem Elements using an "interaction matrix". Each Problem Element is given a numerical index associated with a row and column of the matrix. The team considers each Problem Element in turn with the others. If the solutions implied by one Problem Element (i.e., the forms that resolve the forces to achieve the functions) tend to reinforce or conflict with those of another, the Problem Elements should be considered together in the same mindset. They are consequently marked as interacting where their respective rows and columns meet in a cell of the matrix. (Problem Element "x" is considered with "y", and "y" is considered with "x" in the matrix to provide a sanity check. The matrix should be symmetrical along the diagonal.)

In large complex systems design problems the goal of the analysis is to define the forces that need to be resolved by the form to achieve the functions, and the goal of this information structuring is to make it manageable and usable in the problem solving and design synthesis phase. The elements and their interactions defined in the matrix define a non-directed graph, essentially a map of the problem space. The cluster analysis program decomposes this graph into a hierarchy of sets of elements.

6.4.3 Cluster Analysis: A Simple Example

While a real systems design project would involve hundreds of Problem Elements, the cluster analysis can be illustrated by the following simple example. Twenty-one Problem Elements are related on the interaction matrix, defining a non-directed graph, where the numbered nodes represent the corresponding Problem Elements and the edges (lines) represent the interactions between them. When this non-directed graph is untangled, the clusters (or sets) are clearly seen.

Based on the number of elements shared by the lower-order (level 100) sets and the number of links between the sets that bind them together, the cluster analysis determines a hierarchy of supersets. Level 200 sets consist of several level 100 sets, level 300 sets consist of several level 200 sets, and so on. In this way the problem maze is hierarchically decomposed.

A number of computer programs exist to perform the clustering. Those used in architecture and industrial design are typically based on Alexander's original HIDECS (HIerarchical DEComposition of a Set with an associated graph). Perhaps the best of these, Owen's VTCON (Variable Threshold CONdensation) raises and lowers the threshold that "allows" sets to be formed, balancing the number of elements in sets (4 to 10 is a good number) against their relative "connectedness" (around an 80% connection ratio is typical), and it produces a semi-lattice rather than a simple tree.

The advantage of this information structuring is that the design team can consider the Problem Element in each lower-order set quasi-independently from the others. Tentative solutions are generated for each lower-order set, and then integrated with one another using the hierarchy as a map for solution integration. For a simple design project of only 21 elements such an approach is hardly needed, but this is a good way to attack large complex systems design projects with hundreds of Problem Elements because the solution generation can proceed in a discretely manageable and systematic way.

6.5 Design Synthesis

In practice the problem solving or design synthesis phase consists of three passes up the decomposed set hierarchy: (1.) systems design; (2.) systems engineering; and (3.) systems implementation.

6.5.1 First Pass: Systems Design

In the first pass the design team attacks each of the low-order (level 100) sets in turn. Reviewing the documents for the Problem Elements in a set, the team considers the forces behind the problems, the contexts and functions that must be performed, and the solution summaries (implications or directives) and design speculations. It then generates a solution that satisfies the requirements of all the Problem Elements in the set, that is, a form that resolves all of those forces.

Using the set hierarchy as a design synthesis strategy, the solutions for the level 100 sets are resolved, integrated, and fine tuned with each other to create solutions for the level 200 sets. Next, the design team integrates solutions for the level 200 sets to create solutions for the level 300 sets, and so on, until it sketches out a complete systems solution for the superset at the top of the hierarchy.

For creative problem solving this pass is the center of the cyclone. Moreover, any number of "right brain" or "black box" methods and tools may be utilized to foster the creativity of the design team. Specific ideas for detailed design may be noted along the way, but the goal in this pass is to generate a comprehensive and integral solution concept that resolves all of the problems, hence, the solution imagery tends to be abstract and diagrammatic ( not too detailed.

6.5.2 Second Pass: Systems Engineering

In many software projects, the process starts with engineering, often unfortunately based on unjustified assumptions and preconceived or stereotyped solution images. Having gone through the preliminary research, functional analysis and conceptual design phases described above, the systems design solution is more likely to be based on real empirical information, consequently innovative, holistic and integrated.

In the second pass the design team translates the conceptual solutions of the first pass into more concrete design specifications. In this pass the design imagery is more detailed and less abstract: sketches are made, models and prototypes are built and tested; blueprints and engineering drawings are drawn up; pseudo- and real code for programs is written.

A well-formed conceptual solution can still be botched in this pass. Good designers and engineers ensure the system is economical, performs well, and isn't ruined by gratuitous bells and whistles. In addition, the preliminary phases described above aren't geared to specify every little detail; there is still room for experience and common sense.

This is where formal software engineering procedures come in. The best ensure that the project is actually doable, that it isn't going to violate standard interfaces or break anything disastrously, that key groups have buy-in, that it gets tested as you go, and that the documentation won't be left as an 11th-hour afterthought.

6.5.3 Third Pass: Systems Implementation

In the third pass the design finalized in the systems engineering pass is actually built involving a hand-off from development to integration, testing, release engineering and manufacturing groups to be implemented. There may still be some low-level design decisions to be made, for example, those involving fit and finish, and there is always a fair amount of fine tuning as preliminary (alpha, beta, etc.) versions of the system are built and tested.

This pass is not completely divorced from the Structured Planning process. First, a thorough functional analysis would include Problem Elements about ameliorating problems in systems implementation (e.g., making the system easy to integrate, build, diagnose, and support etc.), and the concept development and systems design of the first pass would respond to them. Secondly, care should be taken to carry through the solution concept in this stage. A subsystem whose performance is critical for customer acceptance could be ruined by building it with the wrong compilation tools and environment, for example.