Sunday, May 4, 2008

BPM Frameworks

Business process modeling is something I always thought of as simply a knowledge sharing exercise that takes place amongst a group of folk who simply want to understand either how things operate in an organization, or how they would like things to operate - I guess there are thousands of shades of gray in-between.

Back in 2003, I began working on a project where a specific type of technology was employed where the programmer used business flow charts to actually build software. This particular product was supplied by a major provider of application server software, but was by no means unique to them. 

During that project, I had a problem reconciling my understanding and beliefs on system construction and this BPM/code generation model. I have often thought back to this project and struggled with it ever since, and I would like to hear from others who have experienced this feeling.

It just didn't sit well with me because I like to believe that objects are a reasonable way to model to world in order to understand what a business wants - but I am willing to accept that I might be completely wrong here (if there is a right or wrong answer). However, I temper this last statement with the fact that I worked with a few other good people, all of whom also had some very serious reservations concerning the viability of such approaches to solving problems.

Since it was some years since I last tried to use this approach to building software, I reiterate that I feel I am not as qualified those who have more recently been through this, so please let me know your experiences. I find it hard to put into words some of the reasons why this way of working seemed so alien and ineffective to me, but here goes.

1. Modeling only in terms of the dynamic aspects of a business flow precludes the static view of the system which is a very powerful tool to allow us to consider relationships between things in the problem domain. Yes, we can do this a separate exercise, but (certainly at that time) there was no mechanism to tie this view of the world with the strictly flow chart oriented view.

2. This approach led to lots of code duplication because no real world objects could be generated using a purely dynamic view of our business world.

3. One of the arguments for introducing such tools was that less experienced developers could produce working code less expensively. Actually the converse was true. With good, experienced developers working on the project, we struggled to deliver working software, simply because of the scale of complexity involved. Many mechanisms did not work out of the box and lots of tweaking was required by very smart people to do even the simplest of operations.

4. Another argument was time to market. Due to the largely visual tools, it was claimed that time to market could be reduced, because developers could be many times more productive. Just because tools are visual doesn't mean that things can be produced more rapidly. 

At the time I felt that viewing software as simply flow charts was not taking the many different viewpoints of software construction into account and that the sheer complexity of such tools (even though I don't think they have to be so complex) is actually a developers worst enemy. 

When you put good developers on a problem and they struggle, I know something is wrong. Non-developers would have quickly given up in desperation. Call me cynical but I really saw this a nasty marketing exercise - convince me I was wrong.


Kim said...

I can only agree with your observations. As I see it, the whole concept is flawed, as soon as it is being removed from the paperware universe and brought into the real world, where the devil lies in the details.
I could provide many thoughts about what I find inherently wrong with the approach, but I'd rather focus on THE biggest issue as far as I'm concerned: The idea, that development time can be reduced by "dragging and dropping a bit" (i.e. reducing complexity).
As I see it, the amount of complexity is a constant, that is tightly connected to the business domain, and application development task at hand. That amount of complexity can't be reduced. At the best, it can be controlled, and mastered in a conscious manner. So when the tool tries to ignore and remove complexity in one area (in this case, the upper layers in the development architecture), the result is, that the complexity increases in other areas like for instance Build/Deployment, testing etc.
Another major issue is the fact, that although everything seems fine and dandy as long as everything works as expected, and you "play within the boundaries" set by the provided functionality in the framework/container, things start to go pear shaped, when you need to move "beyond the box", and look under the hood. At the point where you need to extend or tweak the framework, is the time you realize whether it is practically usable, or if it better left as paperware.

Andrew said...

Kim, I like your point about complexity. Whatever gimmicks come and go, the simple fact is that complexity moves somewhere, so where does it go? In my experience it tends to move towards deployment and debugging. If all works as planned, things can go smoothly, but in my experience, things often don't progress as planned.

So then what? Well you have to bring out the heavy lifting gear - your super talented developers. But of course their job is even harder, because generated code is almost always more difficult to debug. Mangled and unintuitive naming, vendor specific mechanisms and often very heavyweight environments make it tough to get to the root cause of problems.

Paul said...

Hi Andrew,

You really know how to press my buttons... don't get me started :)

There is a whole industry based on this type of Snale Oil.

How about these others:


I'd thought I'd get them all out the way in one go.


Andrew said...

Paul, understand your point completely. I have only just calmed down enough to talk about these products more rationally. My past comments were based on four letter words that were only suitable for an open minded, mature audience.

I wanted to take an analytical approach and try to consider exactly why I found them so scary to work with, because I haven't found much column space dedicated to the subject.