March 2007,
Rev 0.2
By John Hansen
To comment – see blog entry.
We have
been working and developing workflows for a period of several years. This white paper is result of that work. One basic conclusion is that workflow automation
is much more than a workflow engine. It
consists of a complete ecosystem.
This paper
does not attempt to explain what a workflow is, nor the features or benefits of
using workflow automation (see references section). The white paper does attempt
to list the attributes required of ideal workflow ecosystem. This could be used as a basis for comparison
of different workflow ecosystems.
A workflow
ecosystem is comprised of 5 key components; not more, not less. The most import attribute in making the
resulting workflows successful is the capability for the user to perform the
design.
No system
will completely embrace all the attributes, but the closer it comes to these
the better the workflow eco-system and the higher the quality of the developed
workflows.
Common Attributes
The workflow creation tool(s) or workflow designer is
the heart of the ecosystem. The better the tools are, the better the workflow
eco-system. Better can be defined by the following attributes:
b. Complexity – namely
what skill level is required to use the tool? The lower the skill
level, the better.
c. Visualization which is
how well the tool helps the user visualize the problem.
Visualization can be measured by compactness or the size of the representation.
d. “In situ”
operation. Can the designer operate in the workflow execution
environment? For example, if it is a workflow web system, can the
designer operate in a browser? This answer is not necessarily
binary.
e. Non-iterative
design: Does the workflow designer support complete operation
without an iterative process, such as add a construct, change the database,
regenerate and if there was mistake go back to change the construct or
database. The less iteration the better.
f.
Object Oriented: The tool should be as object
oriented as possible, namely that the constructs employed (such as workflow
designer specific objects, ie activities) should be
object oriented.
g. Extensible:
The workflow designer should be a framework that can be extended.
2. Object persistence and
accessibility.
Most workflow eco-system objects need persistence and need to be multi-user,
multi-system access. The attributes are:
a. Object
Oriented: The measure of how pure the objects are with respect to
the OO ideal. The best would be simply to have persistent objects
where the user, be it programmer or workflow designer wasn’t aware that the
objects where stored in a relation database. This implies the OR-mapper, if used should be built from the object
perspective, not the database perspective.
The implication here is rather profound since many systems are built using OR-mappers and they provide a database perspective. They
need to primarily support persistence, without exposing the storage medium
which typically is relational database. Users should be concerned with
the data and its schema, not its storage mechanism, native schema and the
mapping process.
b. Objects need to have
universal accessibility (i.e. over the Internet) and need to support,
inherently, atomic operations.
The most common technique for visualization and interaction is
an electronic form. Other
visualizations are gnat charts, state diagrams and flowcharts. The basic premise
is that not a single visualization works in all applications (multiple forms
are required). That being the case a certain amount customization
is required.
a. Customization
capability. A programmer only generated form would rate low, a
programmed custom visualization system with user selectable attributes would be
better and a fully user defined, in situ, visualization system would be rate the
highest.
b. Canned visualization. Is there canned or predefined visualization? Is there a set of default interfaces that can
be used?
This is viewing data using one or more of the following
attributes - by time, by category or by some sort summary. Typically reports
are in tabular format, but other formats such as gnat for time oriented data
may be more appropriate.
a. Can it show the
objects directly? Many reporting systems
work on the database, which may map directly to the workflow objects, but not
necessarily. Many database fields have
meanings defined by the workflow rules or the form, therefore reports that use
actual objects would guarantee getting the correct meaning.
b. Can reports be
generated in-situ or do they need to predefined?
c. Are the reports
compatible with display standards be recognized or de facto (ie W3C XML, csv or Microsoft
Word)?
This has been purposely placed last. Although workflows can’t exist without an
engine, the engine by itself is merely another programming technique.
a. Workflows, in
progress, should be able to resume operation on any other workflow engine in
the environment.
b. A single workflow
should be able to support simultaneous operation on multiple devices. This is
to support non-connected systems, such as PDA or notebooks.
c. The ease at which a
programmer can create workflow library objects such as activities?
d. How Object Oriented is
the workflow engine? This is based on
the premise that OO is a very good programming model and a workflow engine is
merely another programming environment.