In my practical experience with SOA, at it's core what it really means is discrete codebases for discrete functionality within your application. So while you CA

In my practical experience with SOA, at it's core what it really means is discrete codebases for discrete functionality within your application. So while you CAN operate in separated environments, you don't necessarily have to. Although the article seems to approach SOA only via web services, that's not the only way to do it and there's no reason why the service can't be consumed as a library. When it comes time to scale, it's trivial to prop that API up behind a web service interface. There is nothing wrong with scaling the entire application to meet the demands of one specific module / bottleneck, however, this isn't always a cost effective option. I've found that scaling entire monolithic applications often means throwing more hardware at the problem whereas scaling a service may mean only configuring your server environment to better meet the technical problems of that specific service (example: picking a data store that matches the storage, reliability, and I/O requirements of the specific service which may vastly differ from other components in the application). I agree with your third point. Having many small parts makes the individual modules and functions simpler to understand, but it does not make your system easier to understand as a whole. SOA is a great approach when you have a defined set of requirements that you know will not be changing significantly so you can create interfaces that can remain as concrete as possible over time. This is why SOA is a great solution for the enterprise. The advantage of a monolithic application allows for rapid prototyping because the individual components can be built quicker -- it's much easier to test if a component is a benefit to the actual business objective that it's serving. In the handful of applications I've been in charge of developing that have matured and grown over the years, they've all started as a monolithic application that slowly grow into a SOA-type approach. As specific components run into problems, they get refactored into their own independent services that the "monolithic" app either calls via a web service or as a library API. Eventually the "monolithic" app exists only as the web frontend with all the heavy lifting being done by services.