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 <[email protected]>
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
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
|
|
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
|
