I think I've gotten pretty good at teaching people about SOA, not due to talent as much as just the number of times I do it.
Thus, when I look around the SOA-sphere, I'm always on the lookout for others that also explain SOA well, such as Uncle Bob who posted his explanation here.
"Software developers have known for years that software that changes frequently should be decoupled from software that changes infrequently. When applied to individual programs and systems this principle is sometimes called The Common Closure Principle. When it is applied to the information management of an enterprise, it is called SOA."
Indeed, SOA is not just about defining services and assembling them into solutions; it's about defining the right services, typically placing volatility in their own domain. Thus, change is not as painful for your architecture, thus the agility value, thus the reason we are bothering with SOA in the first place.
