Chapter 2
Shhh, Don't Tell Anyone, but Let's Talk about Service-Oriented Architecture
The last chapter introduced Service-Oriented Architecture (SOA) as a type of Agile Architecture. So, what is SOA anyway? Whether or not what you're doing is actually SOA is somewhat of a pointless question; after all, what matters is whether what you're building actually solves a business problem. It doesn't really matter if you can call it SOA or not. But be that as it may, there's still widespread confusion and ongoing misinformation in the marketplace as to what actually qualifies as SOA, so this question is more relevant than maybe it should be. Here, then, is how we go about making the line between SOA and non-SOA clear.
The first point to remember is that SOA is architecture; in other words, a set of best practices for the organization and use of IT to meet business needs. This criterion, however, sets the bar quite low, because virtually any implementation follows some sort of organizational principles. Whether those principles are best practices, furthermore, is open to interpretation.
The second point, then, is the fact that SOA is an architecture oriented toward Services, and thus the definition of “Service” and whether the implementation follows an architecture that is oriented toward such Services becomes the critical question. The problem here, though, is that the word “Service” has several different meanings, even in the context of IT—and defining a criterion that SOA must be oriented ...
