|
In the 1990's, workflow vendors created quite a bit of confusion in the market when trying to define workflow and how it could best be utilized. Today, that situation is being replicated in the BPM industry. Ask 10 different vendors to define BPM or BPM suites, and you will likely get 10 variations of the definition, even though all vendors use the same basic terminology to explain it. Organizations need help sorting through this confusion in order to discover why a BPM suite is a different, and more important, application for process improvement.
The Workflow Solutions of the ?90's
Let's start with a little background. The workflow solutions introduced in the 90's primarily consisted of an engine and a language. Many solutions also included some type of graphical modeling environment, albeit rudimentary. Only a few included a more robust, UML-based modeler; more likely it was a proprietary modeler.
The modeler generated code, normally in the form of some proprietary workflow language, although there was some convergence around the main standards like WFML or XPDL. Both offer XML-based primitives in which process patterns are used to describe workflows. The engine interpreted the code and executed the workflows. Changes or de-bugging typically occurred in the code, as opposed to inside the modeler.
At execution (run-time) many elements of managing tokens (representing tasks) were built into the engines, like queuing and prioritization. Therefore, the aspects of controlling a workflow's behavior could be programmed more easily using these engines and tools, because the basic notions of what kinds of objects flow through a process ? such as tasks, or tokens representing tasks ? were built-in.
These engines also looked at which resources were involved and consumed during the execution of these tasks. So concepts like organizations and/or systems were built-in and the engine kept track of things like ?how many tasks are currently in user X's inbox.'
Because these workflow systems primarily assisted the developer in areas where "tasks" were assigned, and "workflow patterns" defined the movement of those tasks, it made sense that most uses of these engines were in areas where other programming activities were minimized. That is, when developing automated solutions for processes where workflow and task handling were the primary requirements, workflow engines offered the highest leverage. For example, in imaging and document management systems, automating processes were not about the business data flowing through the process because it was unstructured to begin with. If you simply attached a pointer to the document or image, the rest was handled by the workflow engine.
In processes where a lot of structured data existed, there was extensive custom coding required to build database tables or object models. It also required a lot of integration if there was structured business data, because the systems-of-record had to be touched by the process application. So while the workflow engine provided benefits, it was less beneficial as a percent of the total code that needed to be written in these situations. Additionally, workflow engines typically made a major flawed assumption in these situations; that they knew about the various resources and that they maintained all states of a process. But when you are interfacing with other systems and those systems perform parts of the process on their own, the state is passed back and forth. Working around this required additional programming.
Furthermore, if the requirements were less focused on workflow and more on tying multiple systems together, it was often much easier to code the application without a workflow engine. Otherwise, the mixed paradigms (and languages) often presented skill-set barriers...not to mention difficulty in the subsequent understanding of a program by new people.
|
