How Systems Design Themselves

Daniel Dumke — Wed, 02 Mar 2011 08:22:00 +0000

Continuing with on with articles on general Systems Design and foundational articles, today I would like to talk about Conway’s seminal paper on “How Do Committees Invent” from 1968. If you want to read the paper completely, you can do so on Conway’s web page.

In his article Conway describes system design at its most generic level. Be it a system to prevent natural disasters or a new product of a company.

Actors and Stages of Design

Under most circumstances the newly designed system has a sponsor who needs the system for an specific end. The task to can be carried out by the affected organization or an external group.
Two basic milestones have to be reached to continue with the design:

Understanding the boundaries, those can be in place by reality or set by the sponsor of the design
Information about the status quo of the system

The next step is then to organize the design team and set the scope of the the tasks of the sub groups.
The fourth and fifth step are the coordination of the tasks and the consolidation into a single design.

The System itself

A given system can be divided into a number of subsystems. Conway gives the example of the public transportation system, which consists on the top level of buses, trains, planes, etc. On the next level an airplane can be split up into subsystems for structure, propulsion, … and so on.

To illustrate this concept the author draws the following picture. The circles represent a (sub)system and the lines the connections between them.

System and Subsystems with Interfaces (Conway 1968)

This thinking about systems can be deployed for other concepts as well. So not only the “to be designed” system can be described this way but also the organization which designs it.

Systems / Design Group

The system and its design group are related. For a given subsystem x there will be a (part of the) design group (X) which designed this subsystem. The same holds true for the connections between subsystems (eg. x and y). If they are connected, we know that the design teams X and Y had to communicate at some point in time to design the interface.

So the design of the finished system is dependent on the preexisting design of the design group.

This kind of a structure-preserving relationship between two sets of things is called a homomorphism.

To underline his point Conway describes the following example from informatics:

A contract research organization had eight people who were to produce a COBOL and an ALGOL compiler. After some initial estimates of difficulty and time, five people were assigned to the COBOL job and three to the ALGOL job. The resulting COBOL compiler ran in five phases, the ALG0L compiler ran in three.

Results

The author summarizes the following thesis:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Since the initial organization of the design group may not be the right one for the newly designed system, flexibility is a key to effective design. Rewards have to be given to support the design manager in keeping the organization lean and flexible

Conway also takes a short detour, that especially large systems might be prone to failure, since the task of designing those systems is huge and overwhelming so that already the communication within the design group disintegrates, leading to the same result in the designed system.

Conclusion

What effects does this have for a supply chain designer? Can the supply chain be seen an image of the company’s structure itself? How does this affect business and research for the “optimal” supply chain design.

Update: Have a look at the comments below, Eleanor recommends a working paper from the Harvard Business School testing above hypothesis: https://hbswk.hbs.edu/item/first-look-feb-8

Reference:

Conway, M. E. (1968). How Do Committees Invent? Datamation, 14 (4), 28-31

Rate This:

Tags:

design

system

foundations

System Failure

Daniel Dumke — Mon, 21 Feb 2011 09:14:00 +0000

I was looking for more general insights into the topic on why systems fail. I stumbled on a talk of Eleanor Saitta from last years Chaos Communication Congress in Berlin. There is a recording of the talk here and the slides for the talk can be obtained here.

I am going to summarize some of the key points Saitta made in her talk in this article.

Types of System Failures

There are two general types of system failures: Simple and chained failures.

The systems propensity for failure is related to the complexity of the system and affected by the aspiration to increase efficiency, optimality and accelerate the Prozesses weithin the system.

Example of the Determinants of System Collapse

Figure 1: System Effect Circle (in Saitta 2010; from Vinay Gupta 2009)

In many cases, system complexity is very overwhelming. So the task of analyzing why a system fails can be very demanding.

To answer the specific question what kind of failure of the economic system (eg. the near-collapse of the financial system in 2008) leads to the death of one or more individuals, Saitta presents the system effect circle.

The individual is placed in its center, next come the possible causes of ones death, the essential foundations of society (like work, resources, transportation and communication). The last two circles show the underlining concepts to generate and sustain the former items.

Multiple systems are affected by those concepts, the following example should clarify the logic.In Figure 2 Saitta shows the connections between the individual systems and how they affect each other.

Figure 2: Example of Connections within the System Effect Circle (Saitta 2010; from Vinay Gupta 2009)

Preventing Collapse

To prevent collapse systems have to be designed to be resilient. The graphic shown in the example above can be used as a basis for the analysis of “what can go wrong”. These results can be generated by defining the Need-Matrix (Figure 3) for the system in focus.

Figure 3: Need Matrix for System Analysis (click to enlarge; Saitta 2010; from Vinay Gupta 2009)

A system not only consists of the foundation factors found in the Need-Matrix, but also the assets and actors within the system, and the rules which control the the access from the actors on the resources.

The goal for building resilient systems is therefore to analyze the connections between actors and assets and explore how the rules have to be designed for the system to work effectively.

Conclusion

Building resilient systems is hard on every level. On a large scale (eg. banking system) existing power distributions often prohibits the establishment of a resilient infrastructure. Nonetheless an in-depth analysis might help prevent the most severe consequences.

For smaller scale systems, like a supply chain, analyzing the foundational factors, actors, assets and rules is mandatory for building a resilient system.

The key concepts are the same on every level: actors, assets, their connections and access rules.

Update:

You can find more on the Simple Critical Infrastructure Model on these slides by Vinay Gupta.

Rate This:

Tags: