Premature Termination

The deeper I go into any BPMS the more I get the feeling that it really is a specialized IDE (integrated development environment) for creating applications for structured business processes.  I think that more customers are coming to the same conclusion and the understanding that a BPMS is a tool for the IT department, not the business. I’ll make a bold claim here – there are no business users of a BPMS, a BPMS is used to create applications for business users, but the BPMS is used by IT. There I said it. It not that being a tool for IT is a bad thing – it is just that most vendors like to make the claim that their BPMS is really for business users.

Given that, I think that a lot can be learned from other model driven development theory and tools. Since I have been around long enough – I have seen a lot of attempts at creating a generic model driven development environment – none got very far and BPMS is one of the only successes.

In that vein, I just read an article in the latest (June 2011) edition of “Comunications of the ACM” (no not the ACM I usually talk about, but rather the Association for Computing Machinery“. The article is by David Parnas and is titled “The Risks of Stopping Too Soon”. It has a lot of good points – and many of them are relevant for BPMS users (I’ll paraphrase some of the key points) but first I’ll start with a quote he gives from Dijkstra: “everytime someone draws a picture to explain a program, it is a sign that something is not understood” –  I would say them same about BPMN, but that is another post.

1. A diagram (Jacob’s comment – BPMN is no different) is a good way to begin understanding something, but usually stops too soon. The developer (or business analyst) works on the diagram until it means something to them and the group they work with, and then they stop. They stop even if the diagram does not contain all the needed information or does communicate clearly to others. A diagram is always an incomplete model.

2. Premature termination also cause problems in documentation. To be honest I haven’t found to many people discussing the issues of documentation that must be provided with any application created by a BPMS. I guess there is an underlying hope that the resulting application will be so intuitive that it won’t need documentation or that the model is also the documentation (maybe that is why I am seeing more focus on user experience in applications created using a BPMS). One of the most important things documentation can do is explain how the “odd-cases” and exceptions are handled – in my experience BPMS driven applications are especially bad at that.

3.  Testing and inspection. No news here – any computer program has these problems and using a BPMS doesn’t make you immune. It is not that developers don’t do testing – it is that it isn’t clear when to stop. I remember a comment someone made to me when I was a junior programmer “bugs always come in pairs”. Jacob’s comment – It is  not clear whether model driven development (ala a BPMS) makes testing easier or harder – but it certainly doesn’t lower the need for testing.

So there you have it – 3 insights from software design that I think can be applied to any BPMS project.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: