One of the questions that fascinated economists and B-school professors of the 20th century had to do with the ideal size of a business. Had the giants that had grown so fast -- U.S. Steel, General Motors and the like -- grown too big? Not big enough? Were they just the right size?
This question boiled down to what was termed "friction," which was what happened every time a transaction took place.
If every clerk in the typing pool -- we're back in the 1950s now -- had to buy his or her own typewriter ribbons, that would mean a lot of friction, a lot of time spent on non-core activity. As businesses grew, that friction diminished, because purchasing departments could handle tasks like that. But if one purchasing department was responsible for buying typewriter ribbons for country-wide operations, that wouldn't be good, either. Clerks would end up wasting time filling out forms "applying" for a new ribbon, and then would waste weeks waiting for it to arrive. In other words, more friction, not less.
There's a good analogy here to service-oriented architecture. The analogy isn't perfect, but the big idea of friction is important.
SOAs are designed in part to promote reuse and eliminate the friction of constantly recreating the same function for different siloed applications. In an SOA, developers don't have to constantly re-invent the wheel, so friction is reduced. Equally important: With SOA's loosely coupled interface, developers don't need to laboriously code point-by-point connections between one element and another. Again, less friction.
On the other hand, with an SOA developers have to comply with a whole new set of rules that didn't exist before. They have to conform to a new set of specifications. More friction. They have to think about how the service they're writing may be used by a complete stranger for a purpose that can't be known in advance. More friction. They need to log their new services in a repository such that others can find them. More friction. Testing is more complicated, because there are simply more moving parts in an SOA. More friction.
The big question is, when all is said and done, will SOAs end up making IT more complicated (and more expensive) than ever, or will they reduce friction? A couple of well-known and well-respected companies have publicly stated that SOA works. (The Hartford and BT are good examples on two different scales.) But for most enterprises the jury is still out.
There's another form of friction I haven't even mentioned, and that's the requirements that SOA puts on networks. I'll get to that in the next post.