Just to chime in with own $0.02.. On 4/27/07, Steve Jones <[EMAIL PROTECTED]> 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]> 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/ > > > > >
