Thursday, April 10, 2008

BPM and DFD, and the art of designing systems

Never heard of DFD? And in charge of designing processes in BPM? Then read this blog posting.

Living in the era of SOA and BPM, I come across a lot of books, articles and blogs that try to tell me how wonderful the world can be. When using a BPM-tool you are able to model and manage the business processes of your company. Flexibility is the keyword. Not only cutting and pasting on a canvas, but also copying to fulfill the popular "reuse" paradigm.

Of course these tools are nothing more than pencil and paper. The art of designing systems is quite another matter. The books, articles and blogs of these days don't tell you very much about the art of designing. We are suffering some amnesia...

Back in the 70s everybody knew that programming was not about writing code, but about the art of designing algoritms. Edsger (Edgar) Dijkstra used the term "elegance" for correctly designed algoritms and everybody knew exactly what he meant. Every programmer and designer knew about Structured Analysis, Structured Design and Structured Programming as rationally described (so not intuitive) approaches to develop systems. Part of these approaches is the Data Flow Diagram technique (DFD). And exactly this technique is extremely useful in the context of todays BPM.

Watch these slides the get a notion:

[click the right-bottom icon to be able to switch to full screen mode]

If you are interested in a more extensive slide presentation then browse through this one:

For you who are the hard cores there is this educational documentation of Ed Yourdon (famous in the 70s and nowadays still actively promoting his timeless methods).

One remark I should make is that you may replace the term "function" by "service" only if applying an additional constraint: the function must be autonomous; the function must be insensitive for its context. That means that the function must be able to execute getting its input from different contexts and delivering its output to different contexts. That makes the function much like a "service" (...don't shoot me!). Mind that Yourdon uses the terms function and process as synonyms (nobody is perfect...).

No comments: