[dasil003]

My point was really nothing to do with whether an application is a fit for SOA. It's more about how to design an SOA. Your point about a poorly designed SOA being an equally poorly designed app is well taken, but I think it's more work to design a good SOA than a good monolithic app. And this is where the effort of designing the interface comes in.

In a monolithic app interfaces can be more fluid because you can have automated tests and static analysis and compile time checks verifying that a given change works. That means you can prototype and iterate faster while the business requirements may still be churning considerably. To realize the benefits of an SOA you need a much more stable interface and some way to handle validation and correctness of the wire protocol. If you do it right and come up with a stable interface, you gain the benefits of decoupling system administration, scalability, and even development to a great extent. But if you do it wrong you end up a lot more work for an equivalent business logic architecture, and if you don't have any scaling issues than the cost-benefit is likely not to be there.

My rule of thumb about whether an SOA is a good idea to pursue at a given point in time is much more related to the team size than the nature of the app.