I have to explain SOA 3 – 5 times a day, depending on what I'm doing that day. It's a common question, and is still a good question if you ask me. 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 ex I have to explain SOA 3 – 5 times a day, depending on what I’m doing that day. It’s a common question, and is still a good question if you ask me. 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. “SOA is the practice of sequestering the core business functions into independent services that don’t change frequently. These services are glorified functions that are called by one or more presentation programs. The presentation programs are volatile bits of software that present data to, and accept data from, various users.” SOA is about the externalization and formation of services, into solutions or abstractions that change often. They can be visual or process/orchestration-based. “Notice that we have yet to mention even one of the plethora of technologies that are so commonly associated with SOA. That’s because SOA is not about any particular technology. Rather it is a design philosophy that decouples well heeled business functions from volatile processes and presentations.” The core point of SOA, and something people often forget in these days of Governance and ESB hype. Again, repeat after me: SOA is something you do, not something you buy.   Software Development