"That's all it is" is a bunch of crap. Neward gives a concise, definitive statement that presents a 100% true or false scenario, which really turns me off. When in software development is ANY decision that clear cut? To me, it seems that software development is all about compromise and tradeoffs.

SOA is not well defined and lots of people have differing opinions. Sure, it is a buzz word, largely because it is so nebulous. The hard part is that it isn't an API or a tool that you can buy. SOA is more of a "philosophy" of how to connect systems to one another.

I feel strongly about this because I've been severely burned when we did not think about contracts between systems. As a result, we cannot release any new application without releasing every other app in lock step.

By following a SOA philosophy, I think you force yourself to think hard about the boundaries between systems. Each system must define "services", and other apps can only interact via those services. Each service should have a well-defined, solid API. Versioning - and resistance to change - must be designed into the service API. You should generally pass simple structures rather than complex object graphs as parameters.

Maybe my definition of SOA is out of whack with most marketers, who perceive SOA as a way to sell expensive tools and get you to use SOAP and a bazillion other web technologies.

Personally, the concept of SOA has really helped me see better ways of connecting apps together.

Note that none of what I describe above is a new concept. You could say the same about design patterns, also. But the term "Service Oriented" is valuable because it helps convey the idea that your app exposes well-defined services, rather than any old random remote method call that will break the instant you change a public method or field.