As always, I separate out the technical issues from the non-technical ones. From a non-technical perspective, I don't think you'll get the full benefits of SOA unless you're also thinking about business processes. From a business standpoint, they are at worst complementary, and in my opinion, should be treated as one in the same. We hear a lot about BPM being the business thing, and SOA being the IT thing, and I think that's an artificial separation.
As for whether or not a process engine is needed, I don't think any piece of technology is a "must." If an organization doesn't have a BPEL engine, what's the alternative? Probably writing Java or C# code. Why would it make sense to use a BPEL engine instead of writing code? The tools that I've seen all leverage graphical designer, which theoretically could be far more efficient for building certain things than writing code. That comes with a flexibility penalty, however, in that there's going to be some logic that just isn't well suited for it. If you find yourself writing custom actions in Java, you should asking whether or not the whole thing should be in Java. If the custom action has broad applicability, such as a custom integration adapter, then it may not be such a bad thing, but if it's only used by this process, you've probably just negated the time-to-develop benefit. Another reason touted for leveraging BPEL is time to change. Theoretically, if it's faster to do development, it's faster to change it. There's two questions to ask here: 1) Will the process change? If the process changes infrequently, then it really doesn't matter. 2) What type of changes occur? The change may not even be the sequencing of the process, it may be some business rule change. If both a Java/C# approach or a BPEL approach can leverage a rules engine, they both may be able to support the change. Whether it's code or BPEL, the effort is still a development activity. We're nowhere near the point where some business user is modifying BPEL directly, so you're going to go through the IT release process no matter what. The last factor I can think of is management. A BPM suite may have better management capabilities for showing relevant business information. This is probably a woefully under-leveraged capability, however. How many applications today are instrumented to show relevant business information? It's simply not something IT is used to providing, and so it's probably something that hasn't been requested by the business nor has it been advertised by IT. As for my opinion, I've seen a few enterprises where a BPEL engine could be justified solely on development efficiency alone. It had nothing to do with automated processes, it had more to do with availability of pre-defined activities and how well the typical programmatic tasks matched those activities. If you're simply doing a lot of data-in / data-out type processing, why are you writing a whole bunch of code for it? Of course, you could some of the good code generators out there to obtain very similar efficiencies, so there are multiple paths. The one other thing that I'd add is that when organizations start looking at true BPM, which involves human activities and task management, I do think they'll need to bring in some specialized technology. I hope the technology has improved by then, but I don't think writing a whole bunch of code is well suited for that approach. I don't want to be replicating a task management engine in all of my applications. -tb On Apr 25, 2007, at 2:09 PM, Stefan Tilkov 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? > > Best regards, > Stefan > -- > Stefan Tilkov, http://www.innoq.com/blog/st/ > > > > > > > Yahoo! Groups Links > > > [EMAIL PROTECTED] >
