Wanted to explore the "SOI vs SOA" aspect a bit. I've long held that SOA is not a distinct level of architecture. Some agree that SOA is a style, not an architecture itself. The term SOA does not infer any particular level. One can apply SO principles to any architecture.
Some use the term SOA to refer to an architecture definition, rather than a style. In other words, SOA is EA. SOA infers architecture at the enterprise level. If one is not defining an EA when "doing SOA" then it isn't SOA, it is something else. [Some-- at least Steve ;-) -- equate SOA to BA. I'm omitting BA for the purposes of this discussion.] It is this latter view that seems to weigh in on the SOI vs. SOA topic and seems to have prompted the invention of the "SOI" term. It implies that architecture is not involved. Assuming one agrees with the notion of an "integration architecture" as a possible architectural level, is it reasonable to apply SO principles to the IA? As such, would the IA be an SOA? Is applying SO to IA a poor choice? Is defining an IA a poor choice, as opposed to a more encompassing EA effort? Is redefining the EA (e.g. "simplifying their applications and...") the only reasonable path to business agility? Is business agility *the* primary thing to strive for? -Rob --- In [email protected], Anne Thomas Manes <atma...@...> wrote: > > Most organizations that I've spoken to are using service-oriented > middleware to do integration (SOI rather than SOA). Very few > companies are actually rearchitecting their systems, i.e., > simplifying their applications and data architectures in order to > increase agility.
