In a general sense, a piece of software is made of algorithm + data and executes on a processor. Additionally, algorithm is a type of data, with a further constraint that it is read only. Both data and algorithm share the characteristic of mobility, whereas processor is fixed in space. By mobility I mean that in a networked environment we can ship the data to where the algorithm resides and execute (i.e. Seti@Home), or we can ship the algorithm to where the data resides and execute (i.e. Mobile agents), or we can ship both the data and algorithm to the processor and execute.
In my networked grid of 100 processors I charge per CPU cycle for work. As master of this domain there is nothing that would bring me more pleasure than looking at the management console and seeing 100 processors CPU bound 100% of the time. So, if there is work to be done and there are spare CPU cycles I would want to employ any of the above techniques to utilize the spare capacity.
SEDA (Stages Event Distributed Architecture) is a SOA, which promotes some of the packaging and distribution principles discussed above. The Enterprise Service Bus (ESB) also exhibits much of the required functionality. The architecture and design of the microprocessor with pipelines, caches, load/store unit, arithmetic logic unit, also provides inspirations by abstracting the micro architecture to the level of algorithm, data and processor.
The way we construct software, the abstractions we use and the architectural constraints we embrace (i.e. stateless interactions, context-free services, mobility) will ultimately determine the performance, scalability, usability and maintainability of the piece of software.