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 "simplification" 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. They were taking the direction from the outside development contractor who was supposed to be assisting with use of the workflow application. So what was their recommendation? Several of the processes needed should be built in the database application and not in the workflow application.
The goal in this project is to create a line-of-business application to replace an aging system. In general, the application takes in filings (web- or paper-based), along with a fee, and accepts or rejects the filing. If accepted, data is sent to a database with a history of the occurrence. As future filings from the same entity are expected, the database will add more history over time, giving a longitudinal view of the filer. Given that documents are involved, a content repository is employed; where processes are concerned, a workflow 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, workflow application and user interface. This model allows developers to change any component as needed in the future and, most importantly, allows for process flexibility.
For well over 10 years now, one of the defining characteristics of superior workflow 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. This 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." This 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. The death by a thousand cuts is just as deadly as a single fatal hit on the head. This 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 effort 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 staff who wrote the code. They may be correct in the short-term, but these employees won't be around forever.
SOAs and stand-alone BPM/workflow applications are well-suited. If that sounds like your project, it may take some discipline at the detail level to use the tools thoroughly.
Jim Minihan [bpm@imergeconsult.com], a pioneer of workflow and process management, is an acknowledged expert on automation of service sector enterprises and their processes.
