The idea of being able to use components in many different configurations, without changing their internals, which is of course standard in the real world outside of programming, was given the name ConfigurableModularity, by the senior IBM engineer NateEdwards.
Since many instances of a given software components can run asynchronously with each other, they usually have to be parametrized, normally by means of parameters specified in the network definition, known as InitialInformationPackets (IIPs). Since IIPs are received from ports like regular IPs, the designer is able to shift smoothly between static parameters and regular IPs being received at the same port from other components, which then act as parameters.
In FBP we see a spectrum of parametrization of components, from none (a process is so simple that it doesn't need parameters, or so rigid that its function never varies), all the way to a mini-language - see LittleLanguages - or even conceivably a not-so-little language.
As stated above, some components need no parameterization, while some, like I/O components, need very little, like a parameter specifying a file name or a DDname on a z/OS machine. Intermediate levels of parametrization are those required by the batch Sort, or SQL control language. Note that such little languages do not have to be TuringComplete. It is the network as a whole that has to be TuringComplete. This probably means that at least one process in the network has to be TuringComplete, but most of them don't.
A corollary of the above is that it might be very useful to be able to run interpreters in processes, but the interpreter shouldn't have to deal with multithreading itself. This means that one could combine compiled languages, script languages, SQL and other interpreters, all in the same network. This seems to me to be a very powerful concept, and a much better approach than trying to cram every paradigm and methodology into a single language.
For a sketch of a declarative language that could be run on one (or more) of these cooperating processes, see http://www.jpaulmorrison.com/fbp/bdl.htm.