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] [mailto:service-
> [EMAIL PROTECTED] On Behalf Of Peter Madziak
> Sent: Saturday, April 28, 2007 12:08 PM
> To: [email protected]
> Subject: Re: [service-orientated-architecture] BPM & SOA
>
> Just to chime in with own $0.02..
>
> On 4/27/07, Steve Jones <[EMAIL PROTECTED]
> <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]
> <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/>
> > >
> > >
> >
>
>
>
