Many folks despise "integration" and strive to eliminate it at all possible cost (not saying that is the case with the audience here). Integration is a dirty word--even though it is a key element for any sizeable environment. "It takes too long." "Costs too much." "Is too inflexible."
I argue that SOA attempts to address these concerns by taking a total system approach: * Identify the high-level services that make up the business * Focus on services, not applications * Define the interfaces to those services *as a matter of course* not as an afterthought * Standardize the interfaces to the extent possible/reasonable/desirable SOA, from one POV, is the evolution of integration practice. Instead of creating interfaces in an ad hoc fashion, assume that others will need to interface with your service and define it right now, not later. Think about how your service will be used by others--even others that you don't know about yet. One could argue that SOA is "integration done right." But as Anne points out, focusing on integration risks assembling things the same ol' way. Services definitions come first and as part of that come the interfaces, which are key for integration. -Rob --- In [email protected], "Nick Gall" <nick.g...@...> wrote: > > Doesn't the suspicion that SOA is vacuous grow stronger when you see > that we can't even agree about the relationship of SOA and > integration? >
