Hi Alix,
I think EA and SOA do share the same goal which is in summary have an
IT that is better aligned with the business.
While SOA is a mean to achieve this, EA is the process of realizing that.

I think EA is a more holistic approach, often (always?) top-down.
I believe that companies where a working EA is already in place do
have a higher maturity and have more chances to succeed in an
Enterprise wide SOA implementation project.
At the level of EA tools, we can see that tools are now more and more
supporting artifacts like Web Service interfaces in addition of
business processes.

Here at my company, business processes are defined and managed in the
business perspective while services (and applications) are managed in
the "application" perspective. An application implements/consumes zero
or more of such services and the EA is tracking these relationships.

Now, to answer your question about "how did we sold SOA":
- we didn't sold SOA to the business
- we sold BPM to the business because business process reengineering
is where the benefit can be for the business
- SOA is more something we do than something we sell

Best regards.
Robin

--- In service-orientated-architecture@yahoogroups.com, "Alix Cheema"
<alix.cheema@...> wrote:
>
> I'm currently leading an Enterprise Architecture initiative (based
on the
> good bits of Zachman and TOGAF) that is using 'Service Orientation'
(SO) as
> a central theme. I've intentionally NOT referred to SOA in the
> organisation, because it comes with a lot of baggage, confusion (its all
> about WS, REST etc) and general hatred from the business.
>
>
>
> Our EA programme, focuses on SO across four different perspectives;
> Business, Information, Technology and Infrastructure. Each perspective
> embodies it's own set of services, hierarchy and value classifications,
> among other things. Most importantly SO helps us achieve traceability
> across the EA e.g. how does one type of service (for example, training
> (business service)) relate to another service (for example, registration
> (technical service)) and so forth.
>
>
>
> Traceability has helped us measure and identify key service
attribute, e.g.
> dependency (coupling), value, goals, drivers and consumers (including a
> whole bunch of other stuff e.g. SLA).
>
>
>
> We are using a 'Service Orientated' EA approach, to help the following
> roles execute various tasks:-
>
>
>
> - Strategic Planning, can identify the impact of new business
> requirements e.g. change in law, new compliance reqs.
>
> - Business Unit Leaders, can identify services that they
can share
> and include in their business cases and eventually deliver within their
> projects
>
> - Enterprise Architects can maintain and improve a holistic
picture
> of architecture across the business, helping the CIO to identify
quick win's
> and longer term initiatives
>
> - CIO can maintain a 'service' centric view of the enterprise
> whereby he/she can better allocate funds
>
> - PMO can start to shape and deliver service enabled projects
>
> - Procurement, can push back on suppliers (and work with
them) to
> begin delivering more streamlined SO enabled products.
>
> - etc
>
>
>
> Amongst many business of our initiatives e.g. outsourcing, technology
> refresh, shared services, A Service Orientated Enterprise approach has
> helped us differentiate between core business services (we build, that
> remain with their respective Business Units), ones to outsource
(some one
> else builds and runs) or share (centrally funded capability across
Business
> Units).
>
>
>
> I have not sold SOA into the business, although we discuss it on a
regularly
> basis with IT. To the business I sell what a Service Orientated EA
approach
> has to offer (as stated above). Finally, SO is not simply a single
model or
> approach, it is made up of numerous SO artefacts and methodologies. E.g.
> Service Life-cycle, Service Realisation Methodology etc.
>
>
>
> So, what I'd like to open up with this group is:
>
>
>
> - How have you sold SOA,
>
> - Who are the stakeholders and how do they use SOA (or its
output)
>
> - What did you have to develop to design/model SOA
>
>
>
> Hopefully this will stimulate an interesting discussion that may
help us all
> position and better promote SOA within our respective organisations.
>
>
>
> BTW, we have and have had many IT projects that have said we are
doing SOA.
> Although technically valid, the NET value of SOA is not being
appropriately
> directed. SOA combined with an Enterprise wide approach has been
our key to
> a brighter and more agile enterprise.
>
>
>
> Regards, Alix
>
>
>
>
>
>
>
> From: service-orientated-architecture@yahoogroups.com
> [mailto:service-orientated-architecture@yahoogroups.com] On Behalf
Of Jan
> Algermissen
> Sent: 29 January 2007 09:22
> To: service-orientated-architecture@yahoogroups.com
> Subject: Re: [service-orientated-architecture] Definition of SOA - an
> offering
>
>
>
>
> On 25.01.2007, at 17:29, Mark Baker wrote:
>
> > On 1/24/07, Alex Hoffman <alex.hoffman@...
> <mailto:alex.hoffman%40gmail.com> > wrote:
> >> An SOA is simply a software architecture based on services.
> >> What's a service? A software program that is intended to be used
> >> by another program.
> >
> > Definitions need to be sufficiently precise in order to enable one to
> > distinguish what is from what isn't.
>
> Here is a question that could provide a start towards an
> architecturally meaningful definition of SOA:
>
> 1. In what way does SOA constrain components of a networked system?
> (When I design a component, what am I allowed to do and what not)
>
> 2. In what way does SOA constrain data elements of a networked system?
> (When I design a data element, what am I allowed to do and what
> not)
>
> (Of course the answers to this must be testable to be meaningful).
>
> <throwing-the-gauntlet-mode>
> My take is that SOA does not have to say anything about 1 or 2
> that is testable.
> </throwing-the-gauntlet-mode>
>
> Cheers,
> Jan
>
> >
> > Mark.
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> > fullfeatured@yahoogroups.com <mailto:fullfeatured%40yahoogroups.com>
> >
>