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/ > >
