The next step is to realize that you can use streams to communicate between processes. Stream parallelization is used not just to speed things up but as an easier way to write massively parallel programs.

Instead of bug inducing mutexes and semaphores, you write a series of threads who are only able to communicate between themselves through streams. Each thread possesses input streams to receive data from other threads and output streams to talk to other threads. Each thread is idle until it receives an input from one of the streams. It then performs some processing which can include sending messages to output streams before going back to sleep. A system may possess a large number of threads and

I wrote a pacman this way where interactive object was a thread: the pacman, ghosts, bonuses,... Even the score was in its own thread. Since the game was real time there was a special clock process to generate the ticks to advance through each frame of the game.

Except for the initial wiring up and flow control (when the emitter of the stream is faster than the receiver), the system is easy to reason with and debug. By looking at the stream you can get a high level of visualization.

I guess the next step after that is to realize that you can apply this to the entire system and replace messy one-to-one ESB RPC calls with something like Event Sourcing.