Roy Fielding's dissertation "Architectural Styles and
the Design of Network-based Software Architectures" contains a wealth of insights on how to design architectures. 

There are two common perspectives on the process of architectural design, whether it be for buildings or for software. The first is that a designer starts with nothing--a blank slate, whiteboard, or drawing board--and builds-up an architecture from familiar components until it satisfies the needs of the intended system. The second is that a designer starts with the system needs as a whole, without constraints, and then incrementally identifies and applies constraints to elements of the system in order to differentiate the design space and allow the forces that influence system behavior to flow naturally, in harmony with the system. Where the first emphasizes creativity and unbounded vision, the second emphasizes restraint and understanding of the system context. REST has been developed using the latter process.

So, if you've been following the discussion so far, we have a pretty general method for deriving architectures. That is begin first with the Communicative Acts, design your solution first with these, and then incrementally apply constraints to derive the architecture. If you took a look at the Taxonomy of Software Connectors you will notice that the dimension and subdimensions are actually constraints and that the values are the technologies.

Next topic, figure out what are those constraints?