A number of posts reminded me about a discussion I had some years ago.
Situation: we were introducing advanced output management technology (e.g. a tool + programming language to create applications that were able to receive XML and generate output (PDF's, prints, etc)).
This technology had a number of advantages:
- Quicker time to market
- Powerfull language
- Easier testing (what you see is what you get programming environment)
- More possibilities in layout
The objective was to reduce the code base in the legacy area considerably. In those huge Cobol programs, many were programmed to generate output (line print, so very '70-ies output). Of course, whenever output needed to change - a new product, new rules, a new contract, quote, etc, Cobol programmers would need to start hacking. They did that for years and saw no issue with that. But the business did - waiting for 2 - 3 months of implementation time, a lot of testing, and that 70-ies layout.
The Cobol group had a lot of resistance towards the new technology. One argument was: well, now we can programm the WHOLE application in one language, but with this technology, we will need multiple skills in multiple languages.
Yep. And I explained that we don't use a hammer to crush coffeebeans to make coffee. We use a grinder. And the hammer we use for nails.
The lesson: when requirements ask for a certain solution, pick the right technology for it.
The same discussion I recognize in a number of postings on BPM (Why Java developers hate BPM tools):
http://weblogs.java.net/blog/johnreynolds/archive/2007/10/why_do_java_dev_1.html
http://www.oreillynet.com/onjava/blog/2007/10/do_i_hate_bpm_no_i_hate_bpm_pr.html?CMP=OTC-FP2116136014&ATT=Do+I+hate+BPM+No+I+hate+BPM+Products
The key question is again: what are the requirements, and what is the best technology to solve something. I am sure most BPM featurs you can easily develop in Java. Hell - you can develop a database with Java, but big chance is you don't....
The key advantages with using BPM technology:
- You can change a process quickly
- 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!
- The whole SOA calling is hidden - it helps you to focus on the process and information flow instead of Java and XML
- Process and activities are measured for you, in a standard way.
1 comment:
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.
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.
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!"
I do take issue with:
- You can change a process quickly
- 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!
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.
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.
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.
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.
Post a Comment