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
On Mar 18, 2009, at 12:46 PM, Rob Eamon wrote:
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.
