DOCUMENT Magazine - February/March 2009 - (Page 28)

BPM: IMPROVING THE WAY YOU PROCESS Pay Attention to Your Architecture JIM MINIHAN [], a pioneer of workflow and process management, is an acknowledged expert on automation of service sector enterprises and their processes. IF you have spent any time around software development projects, you know that sticking to the plan requires great discipline. At every opportunity, someone will want to step outside the boundaries for the sake of “simpli cation” or “expediency.” If you’re in charge of the project, there is a constant battle in herding the cats and sticking to the plan. In another, here-we-go-again moment, I recently found myself reminding developers that what they were planning to do was not in line with the architecture they had. ey were taking the direction from the outside development contractor who was supposed to be assisting with use of the work ow application. So what was their recommendation? Several of the processes needed should be built in the database application and not in the work ow application. e goal in this project is to create a line-of-business application to replace an aging system. In general, the application takes in lings (web- or paper-based), along with a fee, and accepts or rejects the ling. If accepted, data is sent to a database with a history of the occurrence. As future lings from the same entity are expected, the database will add more history over time, giving a longitudinal view of the ler. Given that documents are involved, a content repository is employed; where processes are concerned, a work ow application is initiated. As a result, the objective is to build the new system in a service-oriented architecture (SOA) in which we isolate the database, content repository, payment processor, work ow application and user interface. is model allows developers to change any component as needed in the future and, most importantly, allows for process exibility. For well over 10 years now, one of the de ning characteristics of superior work ow or business process management (BPM) applications is the ability to separate process from data or other content that might be used with the application. Once you start to bind components together, your ability to adjust the process deteriorates rapidly. is defeats the purpose of process management — to easily adjust the process in response to the process metrics collected. For many developers, the pressure to make progress leads them toward the “easy way out.” is is particularly true if the solution appears to be a simple enough rule they may have written many times before, but the collection of such shortcuts is what will lead to a future problem. e death by a thousand cuts is just as deadly as a single fatal hit on the head. is is especially so if you compromise your software development, particularly where BPM applications are involved. Suddenly, making a basic change in the process requires pulling out the documentation (if any) and recoding the application — this fact alone will cause a reconsideration of whether or not the e ort is worth it. Next, you will hear the excuses and the “we’ll do it later when we need to do other changes,” and without a doubt, you will also hear the arguments that “changes are no big deal,” especially from the sta who wrote the code. ey may be correct in the short-term, but these employees won’t be around forever. SOAs and stand-alone BPM/work ow applications are well-suited. If that sounds like your project, it may take some discipline at the detail level to use the tools thoroughly. 28 DOCUMENT feb-mar.09

Table of Contents for the Digital Edition of DOCUMENT Magazine - February/March 2009

DOCUMENT Magazine - February/March 2009
Ad Index
Editor’s View
The E-Return
Research Desk
The Hot 10
Heads or Tails
Content Connection
New Products
Don’t Unlock the Waiver of Privilege
Pulling a MacGyver?
The Print Impression
Talking Transactions
BPM: Improving the Way You Process
Brief Counsel
Transpromo Nirvana

DOCUMENT Magazine - February/March 2009