John Reynolds's Blog

Drive the Path (process and data flow)

1. What are the steps?
2. What are the possible paths through the the steps?
3. What data controls the path through the process?
4. What data flows through the process.

When you know these answers, then start your development efforts with the process diagram and use that to drive your development path in this order:

1. Model the process flow.
2. Define the data that controls the process flow.
3. Build "just enough" user interface to allow you manipulate the data necessary to step through all the process paths.

It's absolutely critical that you do these steps in this order at the outset of your project... and once you are done you've got to do the following:

Drive through ALL of the process paths with your Business Sponsors.

If you follow these steps, then you will expose the flaws in the process flow long before you've wasted any time coding up a fancy UI that is WRONG.

The process should drive the UI, but often our haste to show a sexy screen to our Business Sponsors the UI ends up locking us into a bad process model. We've all made this mistake, and we know from experience that it screws things up for the rest of the project's life.

Everyone focuses on UI. It's the most visible aspect of a project and the easiest to have an opionion about... But in truth the best UI in the world won't make the wrong process right.

Yes indeed... the UI development tools in some BPM suites often require super-human efforts to build the sexy AJAX powered screens that are all the rage, and often you'll end up developing your fanciest UIs with supplemental tools. But that's not why some BPM projects fail...

BPM project's fail when the project team doesn't follow the steps of Process Driven Design that I've laid out in this blog entry. If you've had problems with BPM... try it my way next time. I think you'll be pleasantly surprised if you do.

Comments

• the problem is NOT the developers, it's the managers who decide from a sales presentation that everyone should use some tool for everything.
  BPM tools are sold with the salespitch that they're going to make those pesky and expensive programmers unnecessary, that the analysts and managers will be able to click and drag together the entire application. It's of course a ruse and pretty soon the very expensive tooling is turned over to those programmers with the message to use it as it's already cost a lot of money, and there's a ton of code generated in the tool's repository that's impossible to use outside of it.
  Whatever your salespitch, we who see the end results of the adoption of BPM aren't going to be swayed by it.

  Posted by: jwenting on February 11, 2008 at 07:19 AM

• jwenting,I totally agree that BPM tools are not meant for everything... But when you really are addressing a PROCESS problem they are invaluable when used correctly.-JohnR

  Posted by: johnreynolds on February 11, 2008 at 07:28 AM

• maybe, but in those cases you're doing something that's outside the scope of programming.
  And it still leaves the fact that BPM tools are designed in such a way that they give people the impression that this is the one tool they'll ever need until the point where they get stuck and find that there's no way to take what they have and use that outside the tool.
  I've seen such tools advertised and demoed for a decade, a (now defunct) company I used to work for was even a reseller for one for a time, and they've not changed a bit in either their actual scope, their intended scope as presented in their sales pitches, or the disparity between the two over that time.
  Unless and until the creators and marketeers for these tools start getting more realistic and place them in the market where they belong rather than as a Swiss Army knife that will put programmers out of work, they'll not get acceptance outside of the scope of projects that are bound to fail.

  Posted by: jwenting on February 12, 2008 at 01:29 AM

This work is licensed under a Creative Commons License.