One way is to break the problem into two parts:
Another is to approach robust software from four directions:
Looking at each in turn:
Single Apps
A large application is qualitatively different than a small one. How can we characterize this difference? Are there a set of fallacies we can identify (similar to the Eight)?
A large single applications is usually made up of many tightly-coupled components (including libraries). Are there better ways than !APIs & method calls to connect these components together? If some components are moved to different machines then how can a developer specify to connect them? Jini is a low-level answer (i.e. do it all in the code). What is a higher-level solution? Can we generalize from looking at J2EE containers and the associated deployment descriptors used by J2EE apps?
Systems of services
We can start with Deutsch's Fallacies, but should be able to add others. E.g. Applications need to run continuously, not just do a one-shot, brief computation.
A distributed application can be described as a network of components. Is that a good definition? It seems too low level to me, so what higher-level abstractions can we use to produce a better description?
Networks
It seems like there are also interesting questions relating to the properties of robust networks. (I thought I heard Kristen say this was an area she was interested in....)
Social Organization
Finally there are all the questions about how to organize developers & companies to create complex, distributed applications. How "Open Source" or "Agile Software Development" fit into possible answers remains to be seen.