tag:blogger.com,1999:blog-36915254.post5663395690742489423..comments2023-02-21T11:18:49.135+01:00Comments on Process transformation - interventions for meaningful change: The right technology for the right functionalityRoeland Loggenhttp://www.blogger.com/profile/02744153944427657174noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-36915254.post-45159600386866710022007-10-14T02:17:00.000+02:002007-10-14T02:17:00.000+02:00I don't think anything in your post is wrong. Inde...I don't think anything in your post is wrong. Indeed, and I know I gave it short shrift in the original post, but I do love some of the stuff in BPM tools, I just don't think anyone has made a *good* one yet.<BR/><BR/>I noted in the comments that long-lived asynchronous process are one of the areas where I think, to pick one, the JBoss BPM product really shines. <BR/><BR/>The problem here is the experience of working with the BPM products, not the concept, or even their functionality. I would love to see a BPM tool (and on a similar point, and ESB product) that I looked at and said "now THAT is the way we should be doing this!"<BR/><BR/>I do take issue with:<BR/><I>- You can change a process quickly<BR/>- The process diagram reads (most of the time) quicker than 10 pages of a programming languages, heck - maybe some people on the business side even understand!</I><BR/><BR/>To your first point, you are assuming that there couldn't be a *non* XML-derived DSL for writing these. My problem with BPEL isn't the functionality, it is the developer experience.<BR/><BR/>On the opposite side of this "Enterprise" talk is the raging Dynamic vs Static language discussion -- shorthanded to Ruby vs Java. I don't take an extremist position here. I think both static and dynamic languages have their place, but I do think that anyone that advertises the "One True Way" is wrong. In this case, I think the "language features" of BPEL are mostly spot-on. The problem is the syntax and the tooling.<BR/><BR/>To the second point, there is no reason a simple DSL couldn't be just as "rendereable" to a format that the "business side" could "understand." We have had UML tools, for instance, that will reverse various flavors of code to visual representations for years. Indeed, taking a DSL that is programmer and editor friendly and rendering it to an actual flow chart would be better for "the business side" that DnD "development tools" that render hundreds of lines and boxes for each discrete data mapping aspect between services that, quite frankly, the "business side" could care less about.<BR/><BR/>In short, the problem here is one of expressiveness. BPEL is not expressive enough for "programmers" and TOO expressive for "business analysts." There is no good reason we should have to live with this, other that laziness on the part of BPM product vendors.Robert "kebernet" Cooperhttps://www.blogger.com/profile/03336622901079453553noreply@blogger.com