Architectural patterns
I was just reading Ari’s insightful post on architectural patterns. He draws a distinction between two main architectural styles – 1) a collection of shared-world loosely coupled services that can be invoked in any order or 2) a partitioned, tightly-coupled workflow-based app.
“Shared-loose” seems to match how many people describe SOA right now. However, it seems like I’ve seen a lot of SOA rewrites for apps that are really “partitioned-tight”. They take various subsystems (and/or layers) in the tightly coupled app and break them up into loosely coupled services.
My outside impression of these SOA rewrites from was that in many cases they seemed kind of dumb, primarily because they changed the way the system was put together (in implementation) without changing how it was structured. They introduced a ton of latency into the hard-wired workflow (which still existed anyways). They exposed internal subsystem interfaces as external service interfaces, which usually were too fine-grained and thus caused a ton of extra communication. And they dramatically increased the number of moving parts in the system, greatly increasing the complexity of operations.
So, the end result is that you have the same partitioned-world, tightly-coupled, workflow system but now spanned over an SOA implementation, with an end result that the system was a lot slower, more complex, and more fragile (since everything still had tightly-coupled interfaces).
I can definitely imagine the same SOA system going the next step to actually restructuring their architecture as well, but it’s a lot more difficult jump. They may never survive the first restructuring towards SOA to reach that point.
BTW, I’m not trying to imply that the partitioned tightly-coupled architecture is bad by the way. When I was at MetaMatrix, our server was designed that way, with good reason. The big benefit is that it minimizes latency and we were able to make query processing really fast. You can get scalability and high-availability with either approach but I think it’s harder to get low-latency with a loosely-coupled pattern.

Hi! My name is Alex Miller and I live in St. Louis. I write code for a living and currently work for
Uncle Bob Martin just recently blogged along very similar lines. Additionally, he suggests that SOA is just COA (Component-Oriented Architecture) reborn. Plus, it’s a pretty funny post.
http://blog.objectmentor.com/articles/2007/10/03/soa-cuts-the-gordian-knot-not
Alex,
I have come across several people asking, “is there a flaw in SOA?” I think the question is flawed simply because SOA needn’t be flawed because the application of the technology is incorrect. MANY technologies have been misused / misapplied. In this case, the rule of thumb we setup back in the Walmart.com days was, “do not SOA-enable within the same department’s application.” Its simplistic, but it sort of works.
I have seen SOA successes in cross-enterprise integration. I have seen SOA successes in cross-departmental integration. But, most of the time, within the same engineering group it is still higher performance and just as easy to maintain shared libraries that get compiled in as it is to maintain shared services that do not get compiled in…