With the responses from you and Anne, SOI isn't about architecture but more about the technology used in typical integration efforts. Have I understood correctly?
If so, I'll drop the SOI exploration and continue the SO principles applied to IA exploration. Two main points: * SOA isn't only for making "significant differences." Incremental benefits are okay too. As a style, SOA makes no assumptions about scope. * SOA does not require application rationalization/redundancy reduction. Such an effort can be beneficial for an enterprise but not doing that doesn't mean one is not "doing SOA." "SOA must be applied at something larger than a single application to get anything better than incremental gains." True, but what if incremental gains are sufficient? My main purpose of starting this thread was to raise an objection to the common argument that SOA can only be reasonably applied at the top level architectures. That only SO at the EA or BA levels is worthwhile. That not only is applying SO at lower levels not advisable, but does not constitute SOA. It's something else at best and at worst is something sinister. Gartner's definition of SOA started out as an application architecture notion. Applying SO to one application, or to an integration architecture, may not get you the benefits possible when applying SO to everything, but it is still SO. SOA scope has grown since then but SO applied to AA is still SOA. Strictly speaking, reducing redundancy is not an SO principle. At least I haven't seen that listed in the popular definitions (Gartner, OASIS, Erl, etc.). Indeed, many describe the flexibility gained from SOA is in part due to the (theoretical) ability to swap out one service for another when desired/needed. This implies the availability of redundant or overlapping services. I don't argue that reducing redundancy cannot be a valuable thing. At the EA level such efforts can trim a lot of dead weight. But not doing that doesn't mean you're not doing SOA. Can an integration architecture be SO? Can the integration components be SO when the end-points being connected are not SO? Can an integration effort reasonably create the service front-ends for applications, wrapping them with discoverable services/interfaces and treating the application as the service implementation? Quick definition of IA: An architecture that defines components to provide interaction between (usually existing) end-points. Typically, the end-points cannot be modified to support the desired interactions and are thus often wrapped with an adaptive layer that bridges the integration environment and the end-point. The granularity and scope of that adaptive layer can effectively form a service. Thoughts? -Rob --- In [email protected], Todd Biske <toddbi...@...> wrote: > > Here's my take. SOI, service oriented integration, is probably > best stated as WSOI- Web Services Oriented Integration. It's > simply the act of taking the same integration points that arise in > a project and using web services or some other XML over HTTP > approach to integrate the systems. Could this constitute a service- > oriented application architecture? Absolutely, but in my mind, > there is at best incremental benefits in this approach versus some > other integration technology. Because the scope is a single > application, it's unlikely that any ownership domains beyond the > application itself were identified, so there won't be anyone > responsible for actually looking for and removing other redundant > service implementations. Because the scope of the services > involved didn't change, only the technologies used, it's unlikely > that the services will have any greater potential for reuse than > they would with another integration technology except > that XML/HTTP will be more interoperable, than say, Java RMI, if > that's even a concern. To me, SOA must be applied at something > larger than a single application to get anything better than > incremental gains. Services should be defined along ownership > domains that create accountability for driving the redundancy out > of the enterprise where appropriate. > > This is why an application rationalization effort or application/ > service portfolio management is a critical piece of being > successful. If it's just a "gut feel" that there is a lot of waste > in the IT systems, arbitrary use of a different integration > technology won't make that go away. Only working to identify the > areas of redundancy/waste, defining appropriate ownership domains, > and then driving out the redundancy through the use of services > will make a significant difference. > > -tb
