<<Keynoting the Open Group's Enterprise Architecture Practitioners
conference in Austin, SOA and enterprise integration consultant David
Linthicum described the gulf between enterprise architects (EAs) and
developers on SOA project teams.

"There seem to be two worlds out there, the world of enterprise
architecture and the world of SOA. The funny thing is that those in
each world thinks that they can do the other world's jobs."

He clamed that traditional EAs have "not done a stellar job" in
understanding SOA opportunities, while the SOA folks have not figured
out how SOA itself fits into enterprise architecture. The root of the
dilemma is the fact that EAs are perceived in many organizations to be
theoreticians who reside in ivory towers.

IT consultant Todd Biske of MometumSI, who was also at the conference,
blogged in response that the onus would be on EA to make its artifacts
more relevant to those on SOA's front lines.

"If EA can ensure that the artifacts it creates are consumable at the
project level, then absolutely, SOA will be folded into EA. If EA is
not creating artifacts that are consumable at the project level, then
we have a problem."

And, according to EbizQ analyst Beth Gold-Berstein, who sat with Biske
on a "Future of SOA" panel later in the day responded that SOA project
teams have a lot to learn from EAs, noting that most current SOA
implementations are architecture in name only.

She claimed that most web services today are data services that are,
in essence, conventional remote procedure calls with web services
interfaces. Using conventional RPCs, these rudimentary web services
deliver none of the agility or reuse benefits that SOA could deliver.

"We have a tendency to forget that the "A" in SOA is architecture,"
Linthicum noted. He added that many companies are "managing SOA by
magazine," meaning they want to buy or show that they are implementing
the latest technology without giving any thought to the reality that
SOA is actually a different way of architecting enterprise software
that separates definition of the service from the platform or way that
software is actually implemented.

That was a pretty tough challenge, explained Douglas Darner,
enterprise architect for Chevron. "Focusing on the interface, not the
implementation, was a pretty difficult adjustment for the IT group."
For instance, identifying the process of extracting data from
upstream, wellhead production systems is used by numerous upstream
applications. According to Darner, paying attention to information
architecture was also critical.

"Master data management is hard but critical to the success of SOA,"
he said. "Most users tend to clean up data in Excel. If you leave it
to them, you will get their own versions of the truth."

Our View

By and large, EAs as a group have only recently begun embracing SOA.
For instance, many in this group still fear SOA as opening up the
floodgates to enterprise IT assets in a manner that will be difficult
to control. In effect, because SOA is supposed to make it easy, it
would make it too easy to let software developers-turned-SOA project
teams expose data and application functions in much the same way
taking the familiar shortcuts to turning out quick results without
concern for how their programs could be maintained in the long run.

For instance, CapGemini global CTO Andy Mulholland, a fellow speaker,
claimed that many EAs still view SOA and Web 2.0 mashups with the same
horror that their predecessors greeted PCs back in the 80s: as threats
to the central order of things. In this case, there is the fear that
SOA will make it even easier to expose enterprise IT and data assets,
that could very well fly in the face of enterprise best practices for
managing the software lifecycle, standards for software platform
choices, and of course, compliance with regulatory mandates.

But there was one other point that Linthicum and other speakers
pointed to regarding benefits of SOA: While IT organizations initially
justify SOA projects because of the possibility of reuse, the true
benefit to the business is not the savings from reuse, but the
possibilities brought on because SOA can enable agility.>>

You can read this at:

http://www.cbronline.com/article_news.asp?guid=EF29A3C6-F0F9-4B92-805B-D207D2E92\
DED

Gervas