I am afraid that SO{alphabet}A will destroy the concept and allow a
"flavor" of SOA for compromising the SOA principles on the ground that in a
SOxyzA they are not needed.
I am working primarily with financial Web sites and, in particular, with
Web interfaces for internal and external users. According to Adrians logic, I
have to say that I deal with SOBIA where BI stands for Business Interface.
However, on the basis of plain SOA, I was able to explain my business
clients that the Web site represents an aggregation of business services that
join its business interfaces for business collaborative tasks and that Web
page flow simply reflects the flow of business units of work mixed with the
User Experience aspects, and that an interaction between Web sites is nothing
more than a business process. This allowed me to re-model the Web interface
design as a design of collaboration of business interfaces sitting on the top
of business services currently represented by web applications (that will be
replaces by SOA services in close future). As a result, my business clients
started to address business requirements as interface (vs. service) related
which simplified our life significantly. Here is no Enterprise things at all.
So, I see that SOA works if you start with the business model and stop
pushing business into IT (enterprise or application) world. Things like SOEA
is more than EA or SOA scary me a lot.
- Michael
"grigoriu.adrian" <[EMAIL PROTECTED]> wrote:
SOA alone is misleading if not taken in the context or scope of the
development. After all, it can be applied to any architecture (an
application architecture for instance) and not necessarily to an
Enterprise Architecture (EA).
A note of caution: Enterprise wide IT architecture is often called
Enterprise Architecture.
I would like to call it SOEA (Service Oriented Enterprise
Architecture), a target EA with an SO style of architecture.
For most business people, SOA looks like yet another over hyped
technology. SOA may have its roots in a long history of distributed
components architecture, is usually associated to Web Services
technologies and is often proposed by IT.
But in an Enterprise, services may not necessarily be based on IT. In
fact services can be performed by human beings and/or other non-IT
technologies. A service, as in every day life, is an activity
executed by people and/or technology returning value to its consumer,
at a price.
But at the soul of SOEA, is the business value for the Enterprise.
SOEA is an Enterprise wide Business Process Re-architecting effort
and more, it will require an aligned governance and organization.
SOEA is more than EA or SOA.
EA development is the process of achieving technology and
organization alignment to business processes, strategy and objectives.
SOA, as a style of business architecture, is adding value by
enabling business service re-use, quality of service & internal usage
monitoring enabling payback mechanisms and service contracts. More
there are other benefits from enabling services provided over the
Web, using Web Services technologies and from making possible on-
demand outsourcing as SaaS.
SOEA must have support from top management and involve business since
it requires process re-engineering, technology alignment and firm re-
organization, in other words SOEA transforms the whole Enterprise.
SOEA must be the focus of your business strategy until your Service
Oriented Enterprise becomes operational, after a few iterations.
Once implemented, SOEA becomes a powerful competitive asset.
Thanks
Adrian
more on my view on EA and SOA
blog http://blogs.ittoolbox.com/eai/grigoriu
www.trafford.com/06-0421 "An Enterprise Architecture Development
Framework, Business Case and Best Practices" book
--- In [email protected], "Alix Cheema"
<[EMAIL PROTECTED]> wrote:
>
> All,
>
>
>
> I've been a registered subscriber to this group for some time now,
> admittedly a 'passive' member until now. However, based in past
and recent
> SOA treads, I'm no clearer on what our objectives are and how we are
> supporting them.
>
>
>
> The questions, of 'duh, lets define SOA, what is a service, or how
WS
> compare to REST, are wearing thin and I can't see much 'directed'
value in
> how these topics are helping the group understand, develop and
apply SOA.
>
>
>
> So instead of sitting on my arse and say nothing, I've decided to
make a
> contribution that will hopefully be of some value to the group as a
whole;-
> well, as a minimum it may help clarify or even extend my thinking.
>
>
>
> 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: [email protected]
> [mailto:[EMAIL PROTECTED] On Behalf
Of Jan
> Algermissen
> Sent: 29 January 2007 09:22
> To: [email protected]
> 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 <[EMAIL PROTECTED]
> <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
> >
> >
> > [EMAIL PROTECTED] <mailto:fullfeatured%
40yahoogroups.com>
> >
>
---------------------------------
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.
