Hi Dave,

Herbjörn and the previous respondents talked about the relation of SOA and EA. 
So I'll chip in my two cents on the relation of EA and integration. 

SOAs are not typically built on Greenfield. Gartner 
(http://my.gartner.com/portal/server.pt?open=512&objID=218&mode=2&PageID=466502&resId=501593)
 estimates that 70% of the services in an organization's portfolio will be 
assembled from established assets â€" for example, from legacy (mainframe) 
applications and old (pre-SOA) versions of ERP applications. Integration 
features, such as adapters and translation, facilitate the "on-ramping" of such 
IT assets.

Now there's one final edge in the triangle relationship: how does SOA relate to 
integration? My take: projects touted as SOA are very often just 
service-oriented integration (SOI), at least according to my customer 
experience. There are no processe (only integration processes) and there is not 
much reuse. Service interfaces are used as integration points for systems and 
applications (sometimes these come as part and package of current ERP/CRM 
systems). However, such interfaces are mostly technical, API-oriented, bottom 
up. To create a meaningful portfolio of (normalized) service endpoints, some 
kind of intermediation is necessary. 

Cheers, Thomas.



--- In [email protected], Herbj�rn Wilhelmsen 
<herbjorn.wilhelm...@...> wrote:
>
> Hi,
> 
> According to an SOA white paper by The Open Group SOA is an archtectural
> style that can be used for EA. EA frameworks must be able to support the
> features of SOA
> 
> The white paper can be found here:
> http://www.opengroup.org/bookstore/catalog/w074.htm
> 
> A few quotes from the paper:
> 
> P 6
> Service-Oriented Architecture (SOA) is an architectural style that supports
> service orientation. It is a way of thinking in terms of services,
> service-based development, and the outcomes of services.
> 
> P 11
> SOA is an evolution of traditional enterprise architecture styles, not
> something different. It has new features, which deliver major benefits.
> Enterprise architects must be able to take advantage of these new features,
> and they must therefore be supported by the architecture frameworks that
> those architects use.
> 
> 
> /Herbj�rn
> 2009/4/23 Dennis Djenfer <d...@...>
> 
> >
> >
> > A W wrote:
> >
> >
> > I think there is a similarity and differences between EA and SOA and they
> > are overlapped with each other.
> >
> > I wouldn't say that they overlap. You can use SOA as an architecture style
> > when you do EA. However, if you don't have an EA in place when starting a
> > SOA initiativ, then you need to do things that normally would have been done
> > in EA. I think this is the core of the confusion.
> >
> >  for example, SOA and EA and their corresponding governance reveal a great
> > deal of overlap in their concepts, activities, processes, and outcomes.
> > For example, both require input based on business objectives and produce
> > outcomes that are tied to and measured against these objectives.
> >
> > Well, I would say that this is the essence of EA. You need this whatever
> > style of architecture you choose.
> >
> >  Furthermore, both aim to address issues on the enterprise level (strategy
> > and planning, reference architecture, and so on), and at the same time their
> > governance models are similar.
> > An enterprise that's adopting SOA while developing EA and its governance
> > may encounter problems if the similarities and overlaps between EA and SOA
> > are not recognized and accounted for.
> >
> > It doesn't matter which architecture style you choose, you need governance.
> > Governance is part of EA.
> >
> >  If we look at business architecture domain, SOA address the business
> > processes while EA addresses the business architecture.
> >
> > I've always looked at business processes as a part of business
> > architecture. When I'm working with EA I usually start with the business
> > processes.
> >
> >  >From application architecture domain, SOA address servcies and
> > components while the EA address the application architecture as a whole.
> >
> > Yes, EA adresses the application architecture as a whole, and part of the
> > whole is applications, services and components.
> >
> >  Integration middle ware architecture domain, SOA addresses Integration
> > architecture / ESB, while EA concerns with technology architecture.
> >
> > I've always looked at the technical aspect of integration architecture as a
> > part of the technical architecture, i.e. the choice of technical platform
> > for integration. The semantics of the integration architecture is defined by
> > the information architecture.
> >
> >  Data archiytcure is addressed by SOA while EA address the information
> > architecture.
> >
> > I never know what people mean when the say "data architecture". It means
> > different things for different people. Do you mean the logical and physical
> > architecture for databases? In that case I would say it's part of EA, but
> > not SOA. Information architecture, on the other hand, is an important part
> > of both EA and SOA.
> >
> >  and from operations architecture domanis, SAO addressesQoS, security,
> > monitoring & infrastructure while EA again concerns with the whole
> > technology architecture.
> >
> > This is a concern of SOA and the technical architecture, which is part of
> > EA.
> >
> >
> > // Dennis Djenfer
> >
> >  As Dr. Mamdouh Ibrahim, from IBM advices us, "To reduce headaches in the
> > process, make sure you have well-planned architecture governance and SOA
> > governance models as well as a better understanding of how they should work
> > together. And take advantage of the lessons learned by those who have gone
> > before you�like the ones we've outlined in this article�to save time and
> > money during your own engagement."
> >
> >
> > All the best
> > Ashraf Galal
> >
> >
> > On Wed, Apr 22, 2009 at 2:40 PM, David Chappell <david.chapp...@...
> > > wrote:
> >
> >>  Anyone out there have any nuggets of wisdom on the relationship between
> >> EA and integration architecture?
> >> I know you won't disappoint me :)
> >> Dave
> >>
> >>
> >> [image: Oracle Email Signature Logo]
> >>
> >> Dave Chappell | VP & Chief Technologist, SOA
> >>
> >>
> >>
> >> author, "Enterprise Service Bus" (O'Reilly)  | �Java Web Services�
> >> (O'Reilly) |
> >>
> >> "The Java Message Service" (O'Reilly) | "Professional ebXML Foundations",
> >> (Wrox Press)
> >>
> >>
> >>
> >> 781.359.8729 (office)| 617-510-6566 (mobile)
> >> Oracle Corp | 8 New England Executive Park, Burlington MA 01803
> >>
> >>    [image: Green Oracle] <http://www.oracle.com/commitment>
> >>
> >> Oracle is committed to developing practices and products that help protect
> >> the environment
> >>
> >>
> >
> > ------------------------------
> >
> >
> > No virus found in this incoming message.
> > Checked by AVG - www.avg.com
> > Version: 8.5.287 / Virus Database: 270.12.3/2075 - Release Date: 04/22/09 
> > 17:25:00
> >
> >
> >
> >
> 
> 
> -- 
> Med v�nliga h�lsningar
> Herbj�rn Wilhelmsen
>


Reply via email to