Architectural mobility for stronger software

There’s a concept in sports science that’s easy to overlook because it sounds so basic: “mobility”. Mobility is defined as “the ability of a joint to move actively through its full, functional range of motion with control, stability, and strength“.

If you look at a simplified “athlete performance” pyramid, the foundation isn’t power or strength; it’s mobility. Everything else builds on top of that, but we spend most of our time discussing the upper layers and very little attention is paid to what sits at the foundation of the pyramid. Take away mobility, and the strength will falter.

       / - \
      /     \
     / Power \    Athlete Performance Pyramid
    /_________\
   / Strength  \  
  /_____________\
 /   Mobility    \ 
/_________________\

Now, the reasons why mobility is so important are many and complex, but basically have to do with how the nervous system is able to recruit muscle fibres, whilst at the same time staying healthy (ie. by doing “reciprocal inhibition”).

Putting aside the inherent complexity of the muscles in the human body, I think software systems behave in a similar way, and we spend most of our time discussing the upper layers:

• scalability
• throughput

whilst paying very little attention to what sits underneath all of that.

Most software systems miss something fundamental: they cannot change shape without breaking themselves.

• You move from containers to functions → everything rewrites
• You switch from REST to gRPC → contracts ripple through the system
• You change how remote work is executed → business logic gets entangled

The system might be “strong” in its current form, but it lacks mobility. It’s rarely stated explicitly, and runtime, transport, and protocol are treated as the same decision.

• You deploy to containers → you expose REST → you serialise JSON.
• Or you go serverless → you wire HTTP → you pass payloads around.

Nothing looks wrong and in fact, it feels coherent, but still:

• your execution model has dictated your transport
• your transport has dictated your protocol
• and all three together have dictated your system shape

This affects “architectural mobility” because

• You cannot change where things run without rewriting how they communicate
• You cannot change how they communicate without rewriting what they mean
• You cannot evolve protocols without locking yourself into a runtime

That mobility is what allows your business logic to evolve regardless of any external infrastructure decision, and will allow you to make these deliberate choices:

• do your workloads belong in containers?
• do your workloads belong in serverless functions?
• do they benefit from gRPC, or REST?

In The Pipeline Framework, architectural mobility is enabled by decoupling the transport from the execution platform from the runtime topology, like so:

                     Transport
               (LOCAL / REST / gRPC / Proto-HTTP)
                           ↑
                           │
                           │
                           │
                           │
                           │
                           ●───────────────→ Execution Platform
                          /                (COMPUTE / FUNCTION)
                         /
                        /
                       /
                      ↓
             Runtime Topology
  (Monolith / Pipeline / Modular)

Photo credit: https://unsplash.com/es/@weareambitious