Pure Danger Tech


Architectural patterns

10 Oct 2007

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.