Drive the Path (process and data flow)

Any tools can be used in the wrong way, and I believe that’s the reason many developers hate BPM. They just don’t know how the BPM tools should be used. . .and I’d love to rectify that situation right now.

If you grok Process Driven Development you will love BPM. If you don’t, then you’ll try to use your BPM tools like a traditional application development environment and you will end up with a mess.

It’s all about the Process. . .before you begin development, discover the answers to these questions in this order:

1. What are the steps?
2. What are the possible paths through 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 opinion 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 craft those sexy AJAX powered screens that are all the rage, and often you’ll end up having to develop your fanciest UIs with supplemental tools. But that’s not the real reason that some BPM projects fail…

BPM project’s fail when the project teams get lost… when they don’t follow the steps of Process Driven Design that I’ve laid out in this blog entry. If you’ve had problems with BPM in the past, then try it this way next time. I think you’ll be pleasantly surprised if you do.

Questions or comments? Leave us a note below!