I try to migrate more and more of our IT infrastructure to a Service-Oriented Architecture (SOA), that means separation of independent tasks and implementation of this tasks as decoupled services, simply accesible via HTTP. If you don't like the term SOA, just put in another - the basic idea is to put functionality in little modules and expose them by well-defined interfaces.
It also means a lot of documentation and communication, because people tend to think in integrated systems. When I combine multiple services to a new component, I always take care to catch errors: if one service fails, the rest of the system should keep on running as best as possible. You probably know the Chaos Monkey, which I keep in mind. However, if other people use services, they tend to think in reliable parts. Does good SOA require the robustness principle? In short, if you use a service, you should not expect to much quality: be aware of any kinds of errors: the service response may not contain all information (missing fields), it may include additional, unknown parts, it may respond very slow, or it may not work at all. Is this a property of loose coupling or am I just to lazy to guaranteeing strict service quality? ;-)