I am not sure if I have understood the stated correctly. So what your are
suggesting here are two things-
1. Business as a set of process is at a lower level of abstraction than
business as a set of services?
2. BPM is one of the implementation approach for SOA?
On 4/30/07, Steve Jones <[EMAIL PROTECTED]> wrote:
I think in part this nicely sums up one of the challenges that we have
today, namely that a lot of SOA isn't architecture (which should be business
focused) its design focused (which would be SOD) around technical
implementations. There is a sort of a tiering of elements here which is
SOD = Web Services and development boundaries
BPM = Cross Web Service processes
In this view BPM conceptually sits "above" SOA, and is hugely pushed by
technology vendors as it fits well with the stack based thinking (App
Server/.NET, Development, Web Services, BPEL) which makes selling products
easier. This is the traditional IT product oriented way of thinking.
The other SOA is the architectural one which views the business as a set
of services and then takes that view as a mechanism for the re-organisation
of IT, projects and management to become more business focused. In this
view BPM is an implementation approach for certain types of IT services or
is a measurement mechanism for services ( e.g. Sales). This is (to me) the
new way of thinking that SOA allows. This is beginning to be seen in
vendor's products (e.g. Microsoft Motion, IBM's CBM) but is early days so
isn't overly pushed within the marketing hype yet.
Steve
On 29/04/07, John Evdemon <[EMAIL PROTECTED]> wrote:
>
> Maybe I'm oversimplifying but I see SOA as a design philosophy ("loose
> coupling") and BPM as a management philosophy
> ("processes as assets"). SOA is a means for some of the aspects of BPM.
>
> John
>
> > -----Original Message-----
> > From:
[email protected]<service-orientated-architecture%40yahoogroups.com>[mailto:
> service-
> > [EMAIL PROTECTED]<orientated-architecture%40yahoogroups.com>]
> On Behalf Of Peter Madziak
> > Sent: Saturday, April 28, 2007 12:08 PM
> > To:
[email protected]<service-orientated-architecture%40yahoogroups.com>
> > Subject: Re: [service-orientated-architecture] BPM & SOA
> >
> > Just to chime in with own $0.02..
> >
> > On 4/27/07, Steve Jones < [EMAIL PROTECTED]<jones.steveg%40gmail.com>
> > <mailto:jones.steveg%40gmail.com> > wrote:
> > > 1) BPM is an implementation technology, SOA is a conceptual
> > (thinking)
> > > framework. So all I've ever considered BPM as is "one" of the
> > > implementation choices for a service
> > I agree completely and I'll only add that I sometimes try to frame
> > things relative to service boundaries. So in this sense, I see the
> > orchestration capabilities that the BPM tools provide as just one of
> > the many possible implementation alternatives for inside the service
> > boundary. I make the "inside the service boundary" distinction here
> > because I also see higher-level business capabilities being realized
> > through the choreography of services. The difference is one of
> > centralized control (i.e. orchestration from within a service
> > boundary) versus de-centralized control (i.e. choreography) realized
> > by a bunch of autonomous services doing their thing when they are
> > unleashed in the enterprise. It is in this sense that I prefer to talk
> > in terms of business protocols rather than business processes because
> > that term better reflects the knid of conversational state machines
> > that need to be consider when you dig into how a set of services might
> > converse.
> >
> > Peter
> >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On 25/04/07, Stefan Tilkov < [EMAIL PROTECTED]<stefan.tilkov%40innoq.com>
> > <mailto:stefan.tilkov%40innoq.com> > wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I was in a panel discussion at a conference this week, and was
> > > > surprised to notice there's still no consensus about whether or
> not
> > a
> > > > process engine (or rather, support for automated BPM) is a "must"
> > for
> > > > SOA.
> > > >
> > > > Well OK, not really surprised, but I still would be interested in
> > the
> > > > group's opinion.
> > > >
> > > > There were two views:
> > > >
> > > > 1. BPM and SOA are orthogonal concepts - you can do one without
> the
> > > > other. It's perfectly OK to have a SOA where there is no
> > BPM/Workflow/
> > > > BPEL engine involved anywhere. (This is my view).
> > > > 2. SOA is all about automating business processes via
> orchestration
> > > > of services, so a process engine is a necessary part of an SOA
> > effort.
> > > >
> > > > What do you think?
> > >
> > > Couple of thoughts from me
> > >
> > > 1) BPM is an implementation technology, SOA is a conceptual
> > (thinking)
> > > framework. So all I've ever considered BPM as is "one" of the
> > > implementation choices for a service
> > >
> > > 2) Business Process is only ONE of the ways that a business actually
>
> > > works, and I'd argue its one of the LEAST important areas. Take
> sales
> > > for instance, sure Siebel might have a "sales process" but the
> > reality
> > > is that the sales team will be, if they are any good, fixated on
> > their
> > > goals and targets.
> > >
> > > So what this means is that sure, from a technology perspective you
> > can
> > > do BPM without Web Services, but doing BPM without a conceptual
> > > framework of services is just Visual COBOL with all the flexibility
> > > and agility that COBOL implies. Fundamentally BPM is a
> > > procedural/process approach to design and implementation, something
> > > that has been roundly proven in IT to be a poor way to build complex
> > > systems.
> > >
> > > The only reason for the current fixation on biz process is that all
> > of
> > > the vendors top out at business process so that is what is the
> > > currently philosophers stone of IT.
> > >
> > > Steve
> > >
> > > >
> > > > Best regards,
> > > > Stefan
> > > > --
> > > > Stefan Tilkov, http://www.innoq.com/blog/st/
> > < http://www.innoq.com/blog/st/>
> > > >
> > > >
> > >
> >
> >
> >
>
>
