Here is what Anne's blog has to say on this:

<<According to this report by Jack Vaughn at SearchSOA | TechTarget,
Yefim Natis asserted "SOA is integration" at last week's Gartner AADI
Summit. The assertion produced the usual firestorm of commentary on
the Yahoo! SOA discussion list. Michael Poulin started the discussion
with this comment:

"What can we do to slow down spreading such Integration SOA madness?"

My response followed suit:

"While I agree with the last line ["SOA is less a technology than
a way to dependably extract business value from technology."], I
disagree with the leading one: "SOA is integration". Many
organizations mistakenly perceive SOA as an integration strategy. But
it is not. SOA is about architecture. To achieve SOA, you must
rearchitect your systems. You must remove the deadwood. Every
organization has too much stuff -- too many redundant applications and
data sources. SOA is about cleaning house. You will not simplify your
environment, reduce costs, and gain agility until you reduce that
redundancy."

We have 17 messages in the thread so far, and our debate was picked up
yesterday by Loraine Lawson at ITBusinessEdge. Loraine admonished us
for our "boil the ocean" perspective of SOA. As many SOA case studies
indicate, "SOA" works well for integration. I put "SOA" into quotes,
though, because I assert that these integration case studies are not
examples of service oriented architecture (SOA). The are examples of
service oriented integration (SOI). i.e., they are examples of
projects that used service oriented protocols (e.g., WS-*) and
middleware (e.g., ESB) to integrate two or more application systems.
But from an architectural perspective, you still have monolithic
systems bridged by integration middleware.

Maybe I'm just being pedantic, but I think it's important to
distinguish between integration and architectural activities. It's
fine to use service oriented middleware to implement integration
projects, but then you need to readjust your expectations. Most
organizations that I speak with say that the goals of their SOA
initiative are to reduce costs and increase agility. Unfortunately,
these organizations aren't likely to achieve these goals if their
projects only focus on integration. (Also see Chris Haddad's
perspective on these success stories.)

In the research that Chris and I conducted last year, we found only
four companies that had achieved real success in their SOA initiatives
-- i.e., they met their goals to reduce costs and increase agility.
Their successes were astounding, and they delivered positive returns
on investment in less than 12 months. In all cases these companies
focused on architecture -- not integration.

Service oriented architecture is hard work. It's disruptive. It's a
political minefield. It involves going through the application
portfolio and identifying redundant applications that can be
decommissioned and replaced by a single service. But no one ever wants
to open that can of worms. Many folks live by the adage, "If it ain't
broke, don't fix it." There's way too much other stuff to do. But each
additional application increases the annual maintenance and operations
budget. And for many of those applications, the cost of maintaining
the application exceeds the value it brings to the business. It's just
good business sense to eliminant some of that redundancy. And by the
way, the CFO is going to be looking to reduce the IT M&O budget this
year. There is no better time to start an application rationalization
effort.>>

You can find it at:

http://apsblog.burtongroup.com/

together with a photo of Anne looking very canny!!

Gervas

--- In service-orientated-architecture@yahoogroups.com, "Steve Jones"
<jones.steveg@...> wrote:
>
> Not really, the argument appears to be more about what is integration,
> for instance whether process and choreography count as integration
> and whether more dynamic interaction models count as integration.
>
> I think that most people on this list agree that SOA is
> _predominately_ a governance/organisational/business/thinking thing,
> but that there are SOA _technologies_ which are related directly to
> implementation. One of the on going challenges in this group is the
> two different worlds of SOA.
>
> Far from being vacuous that is in fact the biggest and oldest
> challenge of IT and the point of SOA is that it can have the
> discussion on both sides but its failing is that it still hasn't made
> the difference clear.
>
> Define integration in a tight and specific way.
>
> Steve
>
>
>
> 2008/12/20 Nick Gall <nick.gall@...>:
> > 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?
> >
> >
>