Friction is the aspect of business that's not productive but has to be done.
In an enterprise, it's getting approval from six layers of management before taking action. In a three-person shop, it's attending to details like phone service and buying printer cartridges instead of doing billable work.
The SOA philosophy is designed to reduce friction in IT, but in eliminating some tasks, like hard-coding interfaces, it creates its own forms of friction.
SOA can place a burden on an enterprise's infrastructure, and particularly the network. In a way, this should be obvious. If you have many different entities communicating with one another all the time, as is the case in a composite application, then you're going to have more traffic than if you have only two entities, and a lot of operational problems.
Even more problematic is eXtensible Mark-up Language (XML), which is fundamental to the Web services that are the building blocks of an SOA. The good news about XML is that it's English-like, which means ordinary people can make sense of it. (Well, let's say ordinary people with a technical bent and a tiny bit of programming experience.) But the fact that it's English-like also makes it verbose. Many analysts have argued that XML traffic will put a huge burden on network administrators. Others say it's not so bad.
One solution to XML verboseness is the use of accelerators, which are typically easy-to-install appliances.
Another approach is binary XML. This approach dramatically reduces the network traffic associated with XML, but it has its own problems. For starters, it's not at all English-like, a big drawback. Also, there could easily turn out to be multiple flavors of binary XML, which could eliminate a crucial benefit of SOA -- standardization.