When we say BPM, what it stands for (for IT and for business): business process management or modeling?
- Michael Jerry Zhu <[EMAIL PROTECTED]> wrote: What I want to say here is to pay attention to the evolution of technology, different technology capabilities address issues at different levels of abstraction. Using C++/Java code to do what BPEL does is like using Assembly to do polymorphism. The nature of development activities has changed from 0's and 1's, to assembly, to procedure, to OO, to Service Orientation to BPM. The latest is graphical design. they are not new ones replacing the old ones, but should coexist, There are still 1's and 0's, assembly, procedure, OO, and Services to implement BPM. This is my preference, one may implement BPM using C and skip OO and SO. I think that skip some of the levels of abstruction may be quick to develop but miss future advantage such as reusability or agility or ability to change. For example if we build service using COM objects or Java beans, we could reuse them to implement new services instead doing everything from scratch. Jerry --- Todd Biske <[EMAIL PROTECTED]> wrote: > 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] > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos.
