On 04/05/07, Shashank D. Jha <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
> 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?
Yes
>
> 2. BPM is one of the implementation approach for SOA?
Yes
>
>
>
>
>
>
>
> 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] [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/>
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>
