Computation Through a Systems Architect's Eyes

I approach computation with an occupational habit: I want to draw boxes and arrows. That habit is useful because architecture forces questions about state, boundaries, interfaces, resources and failure. It is dangerous because natural systems were not designed to respect our diagrams.

Computation formally transforms representations according to rules, but a physical system instantiates a computation only under a mapping between physical states and computational states. Different computational models choose different abstractions.

Where does state live?

Computation formally transforms representations according to rules, but a physical system instantiates a computation only under a mapping between physical states and computational states. Different computational models choose different abstractions.

Software gives us the expectation that important state should have an owner. Natural systems often distribute state across structure, concentrations, relationships and history. A snapshot can therefore tell us less than the process that produced it.

Where are the interfaces?

Software architecture teaches that the same computation can run on different hardware and the same hardware can realize many abstractions. That flexibility is why computational metaphors travel so easily.

Engineered interfaces are declarations. Natural boundaries are often material: membranes, tissues, ecological borders, channels, gradients or social conventions. They can leak, adapt and participate in the behavior they constrain.

What is the failure model?

If every physical evolution can be called computation under some mapping, the claim risks becoming too broad to explain anything. A weather simulation computes a model of a storm; the storm obeys atmospheric physics.

Failure analysis is useful because normal operation hides assumptions. A healthy component can coexist with an unhealthy whole. A local optimization can damage the larger system. Robustness at one level can create fragility at another.

History is part of the architecture

Turing and others formalized computation before digital computers became ordinary machines; computer science later exported the concept far beyond programming.

In a designed system, legacy structure may be accidental baggage. In an evolved or historically accumulated system, legacy structure can be the reason the current architecture exists at all. The path is not documentation around the system; sometimes it is part of the system.

The zoom test

A good architectural description should survive zooming. Going down a level should reveal mechanisms capable of implementing the higher-level pattern. Going up should reveal regularities that justify discussing the larger entity in its own vocabulary.

The crucial philosophical question is not whether the universe can be described computationally, but what that description lets us predict or explain.

What evidence would distinguish 'can be modeled as computation' from 'is computing'?

Reading trail

• Nautilus — In the Beginning, There Was Computation
• Aeon — Information theory and life's origins

These links are starting points for the scientific and historical ideas. The systems interpretation, analogies and conclusions here are my own.