Context : OnCities
A fantastic paper "The Information Architecture of Cities" by LAndrewCoward and NikosASalingaros which discusses InformationArchitecture of cities ie. it thinks about cities as information processing systems.
gone but still cached at https://web.archive.org/web/20081205005751/zeta.math.utsa.edu/~yxk833/InfoCities.html
Brief outline ...
City as Information Processing Architecture
It treats cities as information processing architecture.
Movements of people and goods are interpretted as information flows. But an information system is considered to be one which doesn't just move information around. It also processes it. Alternatives are evaluated and decisions are made. For example, humans make decisions about what work to do, what business to invest time and money in according to the information they are fed by the city.
Journeys accomplish a primary information exchange. But ideally (for C+S) journeys have secondary, serendipitous information exchange. For examples, a pedestrian on the way to work visits shops, sees adverts, buys a newspaper, encounters a friend and has a quick word, and may have a coffee observing the behaviour and dress of those around her. This multiplicity of dimensions of information they call FractalLoading.
The virtue of cities is this dense, fractal, multilayered information exchange. It makes cities generate economic wealth and culture. Urban city planners should try to optimize the fractal loading of information.
In contrast, traditionally city planners have tried to
- visually simplify the structure of the city
- design "plug and play" modules, abstracted from their context
in the name of simplifying and optimizing the obvious, primary information flows.
For example, cities are zoned into commercial, living and shopping districts. Joined by high-speed, but informationally 1-dimensional, long distance connections. Large roads are driven through previously complex and rich urban centres, destroying their informational ecology.
These practices are all traditionally criticised by JaneJacobs, ChristopherAlexander, StewartBrand etc. But this paper offers another explanation of the problem. They reduce FractalLoading and therefore information exchange efficiency.
Drawing on the SystemsTheories of HerbSimon the paper points out that all successful complex systems are organized into hierarchies of modules at different scales. (A fractal organization) But cities which are zoned break this pattern.
Hardware and Software Complexity
The authors make a distinction between software and hardware types of complexity :
- Software complexity arises where you have a few types of homogenous modules, and a large number of potential links or flows. The complexity is in the configuration of the links.
- "Hardware" complexity arises from a wider variety of heterogenous modules with fewer links.
(Possibly can be generalized. I have a go at this in TypesOfComplexSystem)
Von Neuman and Recommendation Architectures
The authors make a second distinction between two kinds of succesful complex, information system.
- The "von Neuman" architecture of separated functional modules (eg. memory and processing) with fixed purposes and relationships
- A "RecommendationArchitecture" where similar modules explore and compete. (Similar to competitive layers in a NeuralNetwork especially something like AdaptiveResonanceTheory)
The first of these is closer to hardware complexity, the second, software complexity.
Chaotic and Homeostatic
A third distinction is made between two dynamic trends in systems :
- chaotic ie. the usual sensitive dependency on initial conditions (See ChaosTheory)
- and that trend where complex dynamics fall into a point or basin of attraction, converging from widely different starting points
- to simplify the information required to describe and build the system
- to centralize knowledge of problems and the resources to deal with them. Knowledge of problems needs to be at a high level, but execution needs to be applied at the low, local level. Thus the two levels are forced into a relationship, whier the higher controls or guides the lower.
Thus the systems need to be hierarchies of modules.
Modules are defined not as spatial regions as typically thought of as modules by urban planners. (What C+S call non-modules) But by information flows. A module is a network of information, who's boundary is best defined as the place where external communication is simplified, formalized or standardized ie. is an interface. Elements within the module are highly connected / dependent but modules themselves are weakly connected. (Compare standard interfaces to objects, OnReuse. Contrast WeakLinks which join social network modules but are normally informal. Also my attempts to define individuals in IndividualRecognition)
More on ModularityMistakes
Plug and Play
Attempts to build "plug and play" modules abstracted from their context (eg. a business park) are flawed. They typically misunderstand the nature of modules as defined above. Often urban modules are defined as a spatial region, combining many identical elements eg. office block, business parks, residential districts. These are not real modules at all. Most people interact with elements of different types ie. people live in residential apartments, work in offices and socialize in bars.
Few people travel from house to house. And few companies buy from the company next door in the business park.
On the other hand, these modules are connected to the rest of the city through simplified interfaces eg. one road for the business park. The simplicity is based on the assumption that this spatial area is a module. But it needs to be used for the high bandwidth connections between the elements and the rest of their true modules elsewhere. The result, conjestion.
For some detailed analysis, see TypesOfInnovationInCities
Backlinks (36 items)