Image and Workflow Library:
FlowMark V2.3 Design Guidelines
Bob Stegmaier Mike Ebbers Tomislav Begovac
International Technical Support Organization
SG24-4613-02
SG24-4613-02
International Technical Support Organization
Image and Workflow Library:
FlowMark V2.3 Design Guidelines
February 1998
Take Note!
Before using this information and the product it supports, be sure to read the general information in Appendix C, “Special
Notices” on page 29.
Third Edition (February 1998)
This edition applies to Version 2 Release 3 of IBM FlowMark, Program Number 5697-216 for use with the OS/2, Windows NT and
AIX Operating Systems.
Comments may be addressed to:
IBM Corporation, International Technical Support Organization
Dept. HYJ Mail Station P099
522 South Road
Poughkeepsie, New York 12601-5400
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes
appropriate without incurring any obligation to you.
Copyright International Business Machines Corporation 1996, 1998. All rights reserved.
Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject to
restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Contents
Preface
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
v
v
The Team That Wrote This Redbook
Comments Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
Chapter 1. Introduction and Overview . . . . . . . . . . . . . . . . . . . . . . .
1.1 Basic Concepts of FlowMark
1.2 FlowMark Buildtime: Defining Your Processes
1
1
1
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
Chapter 2. Importance of Process Design
2.1 Function, Performance, and Capacity
2.2 Understand the Basis: FlowMark V2.3 . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
3
3
4
. . . . . . . . . . . . . . . . . . . . . .
Chapter 3. Client/Server Can Mean Multiple Servers . . . . . . . . . . . . . .
5
5
6
3.1 Multiple Server Options with FlowMark V2.3
. . . . . . . . . . . . . . . . . .
3.2 Dedicating Your FlowMark Servers . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 4. How Big is a Process?
4.1 Performance and Capacity Considerations
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
7
7
Chapter 5. Starting and Deleting Process Instances . . . . . . . . . . . . . .
5.1 Starting Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
9
9
5.2 Deleting Process Instances
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Performance and Capacity Considerations
. . . . . . . . . . . . . . . . . . 10
Chapter 6. How Big is an Activity? . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1 Performance and Capacity Considerations . . . . . . . . . . . . . . . . . . 11
Chapter 7. How Many People Do I Assign to an Activity? . . . . . . . . . . 13
7.1 Performance and Capacity Considerations
. . . . . . . . . . . . . . . . . . 14
Chapter 8. When Do I Use an Activity Block? . . . . . . . . . . . . . . . . . 15
8.1 Performance and Capacity Considerations
. . . . . . . . . . . . . . . . . . 15
Chapter 9. When Do I Use a Subprocess? . . . . . . . . . . . . . . . . . . . 17
9.1 Performance and Capacity Considerations
. . . . . . . . . . . . . . . . . . 17
Chapter 10. Data Container Usage . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1 Performance and Capacity Considerations . . . . . . . . . . . . . . . . . . 19
Chapter 11. Using FlowMark Functions Wisely
. . . . . . . . . . . . . . . . 21
11.1 Sign On and Sign Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.2 Shut Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.3 Filtering Work Lists and Process Lists
. . . . . . . . . . . . . . . . . . . . 21
11.4 Refreshing Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.5 Using the Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.6 FlowMark Bundle Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix A. Factors Influencing the Size of a FlowMark Data Base
. . . 25
A.1 Activity Name and Description
A.2 Results of Staff Resolution
. . . . . . . . . . . . . . . . . . . . . . . . . 25
. . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Copyright IBM Corp. 1996, 1998
iii
A.3 Data Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.4 Other Things
Appendix B. The FlowMark Internet Site
. . . . . . . . . . . . . . . . . . . . 27
Appendix C. Special Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
. . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix D. Related Publications
D.1 International Technical Support Organization Publications . . . . . . . . . 31
D.2 Redbooks on CD-ROMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
D.3 Other Publications
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
How to Get ITSO Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
How IBM Employees Can Get ITSO Redbooks
How Customers Can Get ITSO Redbooks
. . . . . . . . . . . . . . . . . . 33
. . . . . . . . . . . . . . . . . . . . . 34
IBM Redbook Order Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Glossary
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
ITSO Redbook Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
iv FlowMark V2.3 Design Guidelines
Preface
This redbook tells you how to design your FlowMark processes to optimize
performance, capacity and resource utilization. This version has been updated for
IBM FlowMark V2.3 and runs on the OS/2, NT and AIX platforms.
It was written for technical professionals such as solutions architects, consultants,
and application programmers who are implementing a FlowMark system. Some
knowledge of FlowMark and client/server issues is assumed.
The Team That Wrote This Redbook
This redbook was produced by a team of specialists from around the world working
at the International Technical Support Organization, Poughkeepsie Center.
Bob Stegmaier is a Senior Marketing Support Representative at IBM's Dallas
Systems Center in Roanoke, Texas, USA. Ever since FlowMark was announced,
Bob has consulted with customers worldwide in all areas of FlowMark and written
technical documents. He has been with IBM for 30 years, including a variety of
programming assignments and 10 years with the Dallas Systems Center. He has a
degree in economics from George Washington University in Washington D.C.
Tomislav Begovac is at the IBM FlowMark Competency Center in Boeblingen
responsible for FlowMark technical support in EMEA (Europe, Middle East, and
Africa). Before his current assignment, he was managing the development tools
department in the IBM German Software Development Lab. Tomislav can be
reached at [email protected].
This redbook was published by the International Technical Support Organization.
Mike Ebbers is a Senior International Support Representative at the International
Technical Support Organization, Poughkeepsie Center. He has worked at IBM for
24 years. He produces redbooks on workflow and image products. Mike
previously developed Education and Training courses on imaging and printing.
Thanks to the following people for their invaluable contributions to this project:
Joachim Schmitz
German Software Development Lab
Boeblingen, Germany
Mike Lang
IBM National Technical Support
Dallas Systems Center
For updating the redbook for FlowMark Version 2.3, thanks to:
Tomislav Begovac
German Software Development Lab
Boeblingen, Germany
Copyright IBM Corp. 1996, 1998
v
Comments Welcome
Your comments are important to us!
We want our redbooks to be as helpful as possible. Please send us your
comments about this or other redbooks in one of the following ways:
Ÿ Fax the evaluation form found in “ITSO Redbook Evaluation” on page 51 to the
fax number shown on the form.
Ÿ Use the electronic evaluation form found on the Redbooks Web sites:
For Internet users
For IBM Intranet users
Ÿ Send us a note at the following address:
vi FlowMark V2.3 Design Guidelines
Chapter 1. Introduction and Overview
Workflow management helps you manage and control your business processes,
pinpoint areas for improvement, and streamline your procedures for speedier cycles
and shorter response times. By defining the flow of work, everyone is notified of
outstanding work and presented with the required information and an appropriate
application to perform the task.
1.1 Basic Concepts of FlowMark
FlowMark is a tool to help you automate and streamline your business processes.
This is critical for success in today's business environment. FlowMark was written
as a pure application-independent workflow engine which manages the flow of work
throughout your organization. It does not have roots in forms, document or image
workflow as some other products do. FlowMark helps you harness the power of
other applications to handle individual tasks. You decide which applications are
best suited to assist you in performing these individual tasks.
FlowMark is designed to handle the flow of work from user to user, following the
business rules specified in your business process. Users have a work list (or
perhaps more than one) where activities are placed automatically when the flow
through a “process instance” determines there is something for them to do. The
users select the next item they wish to work on from the list, and FlowMark calls
the appropriate application program (defined in the process design) to perform that
task. Often it is an application the users already understand. They can work in the
application as long as needed to complete the task. When the program returns to
FlowMark, the server is notified, and navigation continues through the process to
the next activity or activities to be done. These then appear on the work lists of the
people responsible for completing them.
While FlowMark has a user-oriented view, it is also able to include in the process
flow both automatically started activities, that start immediately on a single user's
desktop, and what are called “unattended” activities. These are batch jobs that
expect no user interaction and are started automatically. Some process designs
achieve the same function by assigning an activity to a specific user, specifying that
it start automatically. The program is implemented so that it executes without any
user interaction.
1.2 FlowMark Buildtime: Defining Your Processes
“Buildtime” is the definition facility of FlowMark. This is where you define your
processes and their hierarchies, assign programs to activities, and allocate staff
such as people or roles. The following definition facilities are provided:
Ÿ The Process Definition facility is where you specify and maintain process
models as activity networks. These can involve multiple steps and many users.
The creation and manipulation of activity networks is done with a graphical
interface. An activity network can be considered to be a directed graph, where
the nodes represent activities to be performed and the connectors between the
nodes represent either control flow or data flow. The control flows can be
unconditional or conditional. If conditional, then a Boolean expression is
associated with the connector.
Copyright IBM Corp. 1996, 1998
1
Ÿ The Staff Definition facility is used for the definition of staff personnel to which
activities could be assigned. It maintains information about people, skill levels,
roles, organizations, their relationships and their authorizations.
Ÿ The Program Registration facility is used to register programs that are invoked
at process execution by an activity, and to specify input/output parameters for
the programs. All programs that you wish to attach to an activity (including
those used as “tools”) must be registered.
Ÿ The Data Structure Definition facility is used to define the structure of the
information (in data containers) that is transported from a program to FlowMark
and from FlowMark to a program. The data structures can also be used to
transport data to/from activity blocks and subprocesses.
Ÿ The Server Definition facility is used to define the various FlowMark servers in
an enterprise. All servers to be used for the execution of remote subprocesses
must be registered.
These are the FlowMark Buildtime facilities that you will use to design your
processes. In the use of these facilities, the guidelines in this redbook will come
into play.
2
FlowMark V2.3 Design Guidelines
Chapter 2. Importance of Process Design
The design of your processes is critical to the project and to your business. It must
be done well. You should expect to refine your processes on an ongoing basis.
Since FlowMark provides data in the audit trail on process performance, you can
more easily find the weak points in the processes. Since the “process flow” is now
in FlowMark and not buried deep in a large application, it is easy to make the
changes necessary to achieve the improvements.
2.1 Function, Performance, and Capacity
FlowMark will automate your processes, make them reliable, and see that they run
quickly. If poorly designed processes caused you to move to workflow automation,
keeping the same process design will merely automate the problem. It is important
that you have quality processes defined before you start prototype testing with
users. They need not be perfect, but quality should be evident.
On the other hand, you may already have good processes defined. But you can
use FlowMark to speed the flow from user to user, call the correct application so
the user does not need to remember how, pass data from user to user so it does
not have to be repeatedly entered, and see that the business rules are followed
exactly as defined even when the users do not remember the nuances of particular
exception cases.
Process design touches everything: the way people work, the speed at which things
get done, the results the customer sees (or never sees), the performance and
capacity of the FlowMark server and database, the demands on the LAN, and the
underlying application.
There are no hard-and-fast rules. There are always business reasons to do things
in a different way. But, especially for new users, guidelines can be helpful. As you
gain experience, you can modify these to fit your own business. Included here are
some ideas about capacity and performance. It is never too early to begin thinking
about performance. As you are designing, everything you create influences the
performance of your business application.
Some of your processes may fit easily within these guidelines, while others may
not. If those that fit are the most frequently used (the ones with the highest volume
of instances or activities), your design should work just fine. However, if you do
things that have a negative impact on performance or database capacity, even a
little bit, and they occur many times per hour or per day, the cumulative impact on
your system can be serious. Sometimes it is not so much what you do, but how
many times you do it, that determines the real impact.
It is important to understand the workload volumes in your system. It helps to do
some basic math: the number of instances per day times the number of activities
per instance times the number of users. The result can be enlightening. Additional
hardware can often overcome performance and capacity limitations. Sometimes
that is the right answer.
It is impossible to teach everything there is to know about processes here, but
there are some frequently asked questions to think about.
Copyright IBM Corp. 1996, 1998
3
2.2 Understand the Basis: FlowMark V2.3
The suggestions in this redbook are based on FlowMark as it is implemented in
Version 2 Release 3, the generally available (GA) level of code. As early users find
new and intriguing ways to solve their business problems using workflow, they will
at times desire functions that are not offered or find uses that exceed the capacity
intended by the original design. While the following information reflects some of
these limitations, enhancements are being developed in FlowMark to remove
constraints and provide new functional capability. Please use this only as a guide
for the use of FlowMark Version 2 Release 3.
While this document reflects the implementation in V2.3, you can expect
enhancements. When new releases become available, understand what they
provide and do not let this document deter your use of the added functions.
4
FlowMark V2.3 Design Guidelines
Chapter 3. Client/Server Can Mean Multiple Servers
While FlowMark is a client/server tool, do not limit your thinking and design to a
single server. You should consider capacity and performance in your design, and
there are times when you will need multiple servers to achieve your goals,
particularly if you are designing something larger than a departmental system. You
may need to ask this question: “How many servers, and of what kind, do I need to
achieve my business requirements?” Do not inhibit your design by thinking: “How
do I constrain my design so it works on a single machine?” In today's world of
constantly improving price/performance, hardware may not be as significant an
impact on the overall cost of a project as it once was. Investigate the cost
implications and approach the topic with an open mind.
If you intend to start with a single server, but expect over time to add more users or
more applications to your workflow platform, make sure you plan and design with
the concept of multiple servers in mind. How will you divide the work between
servers? Will you have a different set of users per server, with some people in
each set capable of performing all activities for each process run on that server?
Will you want to eventually move part of a process to a different server while
keeping the “main part” on a current server, thus requiring use of a subprocess?
This planning will make it much easier later when you add additional servers.
Consider the concept of a red team, a white team, and a blue team, each with its
own server, each independently running the same process template, doing the
same kind of work. Or perhaps you prefer different servers with different types of
users doing different processes or subprocesses. Perhaps your application calls for
regional servers serving local offices, running a process that under some
circumstances needs to run a subprocess for headquarters approval. You could
have two or more regional servers, each with its set of users doing the local
activities, and a single headquarters server where that staff does the tasks in the
approval subprocesses for all regions.
3.1 Multiple Server Options with FlowMark V2.3
FlowMark supports servers with OS/2, Windows NT, AIX and HP-Unix operating
systems. The OS/2 and NT platforms give some range of scalability within the
hardware where it runs. AIX gives you a step up in performance and capacity and
a broad scale of available hardware in the RS/6000 family. You can start small and
step up in platforms (even change operating systems) with little effort. This
involves a change of servers, but there is no change required in your process
models; they can be moved as is. Also, there is no change required on your client
workstations. Both server environments support all client environments.
If a single server is not the solution to do your job, what are the options available
with FlowMark V2.3?
Ÿ Simply divide the work. Have different server machines, with different
databases and FlowMark servers for subsets of the users. Divide the users by
teams, by organizations, by location. You will need to have a mix of users on
each server machine so that all activities in the processes you want to run on
that server can be completed by the users there. This could influence your
process design.
Copyright IBM Corp. 1996, 1998
5
The expectation in this concept is that each server and database combination
are independent of any other. There is no communication between FlowMark
servers. However, this solution could, over time, be combined with the
following option.
Ÿ Have processes on one or more servers perform subprocesses on other
servers. This function in V2.3, introduces the concept of domains. A domain is
what most people consider as the “FlowMark server,” the FlowMark Runtime
server and its database. In Buildtime, there is a new selection on the primary
menu called Servers. From there, you define each “server” in the system as an
object along with its network address and communications protocol. Then,
when you create a subprocess icon in process design, you specify on which
server this is to run, on the “Server” page in the notebook. That page also
allows the server to be specified in a data structure member of the process
activity's input (source) container. The subprocess template must be located in
the database of the other server, and all staff resolution (who does which
activities) is done on that other server based on the staff defined in its data
base. This would follow the regional and headquarters example discussed
above.
If you conclude that you need to have multiple OS/2 or NT servers, consider the
other server platform option, AIX. A single fast AIX server can do the same work
as several OS/2 or NT servers. It does involve a change in operating system,
which may have training and skill implications, but it may be the better choice.
These capabilities may not provide you with the ideal solution that you would like to
see immediately. But it is the goal of FlowMark developers to provide you with an
enterprise solution. They are working to give you increasing levels of function to
connect a growing number of users within the overall workflow framework. You will
implement your solution today within the current capabilities of FlowMark, but you
should design with the intent of eventually expanding the horizon.
3.2 Dedicating Your FlowMark Servers
It is best to have your FlowMark servers as dedicated machines. If you put other
applications on the server machines, there is a good possibility that you will
sometimes affect the service you give to your FlowMark users. Even “small”
applications that use resources only occasionally can use significant resources
during the few times they need them. These blips in usage can result in poor
response times for users who are sharing that server.
If you have excess capacity on a server and need to use it for something other
than FlowMark, then understand the risks and keep an eye on what these other
things do. They may impact processor utilization and may also cause conflicts in
memory (swapping) or disk I/O.
6
FlowMark V2.3 Design Guidelines
Chapter 4. How Big is a Process?
How big should a process be? How much of the business should it encompass?
How many activities should it contain? The answer lies somewhere between bigger
than the head of a pin and smaller than a galaxy. Again, there are no
hard-and-fast rules, but some guidelines can help.
If the process has only one or two activities, it is probably too small. If one person
does “this” then “that” and is done in one minute, then FlowMark may not add much
to the work effort. But is this “process” really part of a bigger picture? Look at the
front and back ends to see if these two activities are really part of a larger business
process. Or perhaps there are exception conditions that result from special cases
or errors that are discovered by the work done in these activities. These may show
that you really have a larger process to consider.
If you expect to run the entire corporation with one massive looping process, then
the process is probably too big. A process should represent the steps needed to
satisfy a specific request from a customer or employee. Sometimes you may want
to break a request into multiple processes.
While it is not possible to define the ideal number of activities for a process model,
we can use a guideline of 5 to 20 activities. If you have more than 20, consider
breaking it up by using starts of independent processes or by using subprocesses.
If you have fewer than five, consider combining processes or folding in exception
conditions as mentioned above.
You may begin your first implementation with fewer activities, with the plan to bring
more outside activities into the process model as you gain experience in workflow.
You might automate only a part of a business process, expecting to add more to it
after gaining some experience. Here, a smaller process than the guidelines
suggest would be acceptable.
What about exception processing? Should it be part of the process, or a separate
process? Maybe. (Remember: no rules, just guidelines.) If exceptions are part of
the business and do not last markedly longer than the average process, maybe
they are just part of the process. But let's say you have a process to handle
customer orders and shipping, and occasionally a damaged order arrives at the
customer, which starts a six-month-long involvement of insurance companies,
lawyers, and lawsuits. In this case it might be better to have an activity in the main
process call the FlowMark API to start a separate damaged order claim process
and pass appropriate information in the source container to that process. Allow the
main order and shipping process to complete separately. All the needed
information should be in your application database, available to the damaged order
claim process.
4.1 Performance and Capacity Considerations
Creating a process instance influences both performance and database size. It
involves copying parts of the process template, inserting the new instance into the
database, and then doing some evaluation at the process level, staff resolution, and
updating process lists for those users who have it displayed. As this is a non-trivial
amount of work for the server, make sure there is payback. Very short one- or
Copyright IBM Corp. 1996, 1998
7
two-activity processes (or subprocesses) need to be questioned as they will entail
this overhead, which is much more than just “inline” activities. On the other hand, a
very large process, with many activities and long paths that are infrequently used
because of the transition conditions, can impact database size. The process
instance size is influenced by the number of activities, and the instance takes this
database space as long as it exists, although noticeably less in V2.3 than with
earlier releases. See Appendix A, “Factors Influencing the Size of a FlowMark
Data Base” on page 25, which describes some of the fields in a process template
that influence the amount of data stored for each instance and thus the size of the
database.
If you see the need for a one- or two-step process with both steps done by the
same person, or you have a process where most of the instances are ended by a
single person after a step or two, then consider the following idea. Often the
business event that causes a process instance will record that information in a file
or queue that is serviced by a program that creates the process instance. You
could have a “constant” process, an instance for each person, which has the single
step typically done. When the user selects this activity from the work list, the
program does a “get next” from this queue of work and does the task. It then is
designed to fail the exit condition, so that it goes back as ready on the user's work
list.
If a special condition or exception case is determined which requires further
processing, then instead of setting condition data in the output container to have a
larger process continue, it could use an API call to start another process that would
do that additional processing. This concept can eliminate much of the overhead of
creating very many short processes, yet provides the ability to handle more
complex exception conditions, all using the FlowMark work list as a single place to
find the things you need to do. This can also help in reducing the large number of
people being shown a single item (see Chapter 7, “How Many People Do I Assign
to an Activity?” on page 13).
8
FlowMark V2.3 Design Guidelines
Chapter 5. Starting and Deleting Process Instances
The most obvious way to start a FlowMark process is to open your process list,
copy a process template and start the instance manually. But it is probably better
to provide a simple FlowMark API program to do that. This program could be
accessible to users via an icon on their desktop, or could be called by one of your
application programs that determines the need for a process to start as the result of
some business event.
5.1 Starting Instances
If you have an application that collects many of these requests, be careful when
you decide to start many process instances. Starting 200 instances might be fine
in the middle of the night when there are no users on the system. But a program
that does this during normal working hours will likely take over the server, much to
the detriment of user response time. If you do have the need to process
accumulated queues of requests during working hours, consider programming a
delay in the creation loop to give your users a chance to get their work done.
Investigate the ExmcStartProcess API call. While doing that, consider providing the
instance name yourself. You will find that having instance-specific information in
the process instance name makes using your process list, the monitor and the audit
trail much easier. Customer name, invoice number, account number and other
information might be made part of the instance name.
5.2 Deleting Process Instances
A process instance is called “finished” when the workflow has progressed through
all defined activities to the end of the process. A process instance is called
“terminated” if the process was forced to finish by an authorized user or by the API
call ExmTerminateProcess.
Finished or terminated process instances are automatically removed from the work
lists and deleted from the database if the user who creates the process instance
has checked the checkbox “Delete finished items” in the personal data settings
notebook. It lets you define the following for each user:
Ÿ Activities that have the status finished, disabled, or force-finished are
automatically deleted from the user's work list.
Ÿ Process instances created by the user with the status finished or terminated
are automatically deleted from the database when they are finished or
terminated.
Whenever an instance is deleted, all activities for the process instance are deleted
from the work lists, as are all subprocesses for the process instance.
If the “Delete finished items” checkbox is not checked, you have several other
options for deleting process instances:
Ÿ Delete them manually from the process list.
Ÿ Have them automatically deleted by the server. after a specified interval during
a nightly database processing run
Copyright IBM Corp. 1996, 1998
9
Ÿ Write a program that calls the ExmDeleteProcess API. You can use this API to
explicitly delete individual instances whenever you wish, based on such things
as time and date or other criteria external to FlowMark processing.
The finishing and subsequent deletion of process instances is at least as resource
intensive as creating an instance.
When finishing/terminating and then deleting a process instance, FlowMark
internally has to:
Ÿ Search for the process
Ÿ Update all work lists that an instance has been terminated (even if no clients
are running) to delete finished activities of the instance
Ÿ Update all process lists that an instance has been deleted
Ÿ Delete all data relating to the instance from the database
Ÿ Perform all these tasks for any existing subprocesses
You might therefore want to off-load much of this activity to hours when there is
less system activity and you are not likely to impact the users.
5.2.1.1 Deleting Process Instances and Activities Offshift
By not checking the “Delete finished items” checkbox, you off-load the deletion to a
delete interval defined by the “Days cleanup interval” field on the FlowMark Start
Servers window. The cleanup interval is defined in days. Cleanup is done by the
FlowMark notification servicer, which starts deleting instances and activities at
midnight. Deletion of all finished or terminated instances and activities will then
start when the cleanup interval is passed. Since this happens at midnight, you
need to have the server running at night for this to occur.
5.3 Performance and Capacity Considerations
The basic idea to understand here is that instance creation, and to some extent
instance deletion, are resource intensive. There is a fair amount of work involved
for the server, and there are significant updates (inserting or deleting data) to the
database. It is important to avoid doing much of either during normal working
hours. It is the same load whether you do it by a program that loops or by
selecting many from a process list and specifying delete. If you do significant
numbers at once it will impact your users. If it is possible, defer these efforts until
off hours.
On the other hand, leaving completed instances in your database will take up
database space, and can have some impact on performance. So you need to
make some trade-offs between daytime performance and database capacity.
To summarize this point, you should remove instances from the database as soon
as practical after they have completed. Do it at times where the resource usage
will not impact your users, especially on busy servers.
10 FlowMark V2.3 Design Guidelines
Chapter 6. How Big is an Activity?
How much work should an activity represent? How long should a user take to
complete an activity? For activities that involve the user interacting with a program,
thinking about the problem, and then responding correctly, consider these
guidelines:
Ÿ An activity is done by one person (if you want another person involved, that is
a reason to create the next activity).
Ÿ An activity is done at one sitting (usually there is no long time spent doing other
things in the middle of the activity).
Ÿ An activity should take 5 to 10 minutes or more on average to complete (a user
could be expected to do 5 to 20 an hour and keep that pace all day).
But there are some exceptions. You may choose to keep your process at a higher
level (in application development, write the “class,” unit test the program, and other
things that may take days). A manager's sign-off only takes a minute, but must be
done. Exceptions are not necessarily bad. But when you design one, ensure that
you have a good reason.
6.1 Performance and Capacity Considerations
Typically, FlowMark is used to automate processes of “knowledge workers.” These
are people who are paid good salaries to think. If your design expects a user to do
two activities a minute and keep it up hour after hour, there is not much thinking
going on; that is more of a mindless task. How long does it take to read a screen
or two, analyze the information, make good decisions, and enter some data or a
response? Probably more than 30 seconds.
Consider the potential overhead as you design. When a user selects an activity
from the work list, there must be communication between client and server, the
specified application program must be called, probably loaded from disk, be
initialized, and then communicate with the user. There are applications that take 10
seconds (or much more) when you initiate them from an icon or the command line.
This is a lot of overhead that will impact workers if you have designed what you
believe is a 30-second activity.
Another possible impact of very small activities, particularly for cases where you
intend users to do significant volumes of them, is the affect it has on the user's
work list (it can get very large), and on the network traffic, constantly adding,
updating, and deleting things from the work lists. We will say more about the size
of user work lists in subsequent sections.
There is some amount of work required from FlowMark when you go from activity
to activity in your process. The completion of one activity is recorded at the server,
which performs navigation evaluation to determine what is next, executes staff
resolution (who is to do it), and sends the activity item to those who should receive
it. While perhaps not a major factor, try not to let the overhead of doing something
become a significant part of the work done. Use the tool only where it adds
significant value.
Copyright IBM Corp. 1996, 1998
11
Here is an example. A new customer comes to your retail business. You would
like to keep the customer for a long time so, as part of the “new customer process,”
you gather information into a database. The process design has the following
activity steps:
1. Enter customer and spouse names
2. Enter social security numbers
3. Enter addresses
4. Enter home/work phone numbers, etc.
This is too detailed. It looks more like a program design than process design.
There would more likely be a single activity to "create a customer record." The
application program for the activity might do those things, with different windows,
but there is no need for that level of detail in the process design.
If you have a process that is not heavily used, perhaps one for some unique
circumstances, the size and number of activities has less impact. The real impact
on performance comes when you multiply an aspect by 1000 or even 5000 times
for the number of activities, or when the process template runs every day.
Exceptions to this are activities that are started automatically and do not require
any user interaction (in FlowMark terms, autostarted and unattended). These will
run at machine speed. But a high number of these automatically started activities
can put a lot of stress on your FlowMark server. Be careful if you find that a
significant number of the activities in your process have no real user interaction.
Even significant amounts of work are done quickly at dedicated machine speeds. A
significant number of such activities can cause workloads equivalent to a great
many users working at the 5 to 10 minutes per activity guideline, and will impact
system performance and user response time.
Perhaps another example would help make the point. If a typical user on your
FlowMark system does 100 activities a day (for example, evaluate profitability of a
business proposal, enter information for a new customer, etc.), that would be about
one activity every 5 minutes. It might be possible for a “fast computer” to complete
an activity every 3 seconds. In that case the computer playing the part of a “single
user” could put the same resource demands on the FlowMark server as 100 of
those “5 minutes per activity” users. As always, automatic activities are not
inherently bad; they are useful, even necessary. But understand the implications
as you design your processes, and plan for the necessary capacity in your
FlowMark server(s).
12 FlowMark V2.3 Design Guidelines
Chapter 7. How Many People Do I Assign to an Activity?
There are many options in FlowMark to help assign activities to different people.
These are quite helpful in getting the job done. But do not go overboard, giving
everything to everyone. Think about the implications. Narrow the range of who is
assigned activities as quickly as possible in the flow of your process.
One reason to assign an activity to multiple people is to enable them to do their
own load balancing, all picking from a single list of work.
But there are negative aspects if you “resolve” activities to too many people. There
is more work for FlowMark:
Ÿ It must find each of these people and update their work lists in the database.
Ÿ Then it must send messages over your network to update each person's work
list (when the activity becomes “ready,” then when it begins “running,” and
again when it is “finished”).
Besides, a constant stream of items to a work list can be an annoyance to the
users, because:
Ÿ Their work list will “roll,” since they share it with many others. Activities will
constantly be added, changed, and deleted, as their work list reflects the tasks
of others.
Ÿ There is an increased probability of conflicts. If all users have their work list
sorted in the same order with the same items, all will have the same activity at
the top. When one selects that top activity, someone else may also be
selecting it at the same time. Only one will get it; the others are told that
someone else is doing it.
Of course, you want to design your workflow system to keep the users happy, so
they can get more work done. Here are some ideas:
Ÿ Start with a guideline of three to five people assigned to an average activity
(whether by role, skill level, or organization).
Ÿ Limit the number of persons who receive any single activity to 10 people, or 20
at most. Consider three to five people as the average to shoot for.
Ÿ Although early in a process flow there may be a need to put things on more
people's work lists, try to narrow the number as the flow progresses. The
number may ebb and flow at times, but try to keep it under control. There are
many options on the staff pages in the activity notebook that can help you.
Ÿ Spend some time considering how best to use the different capabilities of role,
organization, and skill level. How will you use them to divide and differentiate
the total population of users? Intelligent use of these staff attributes is what will
enable you to assign individual activities to reasonable numbers of just the right
people to do a specific job.
Ÿ Consider assigning an activity to “whoever” did an earlier activity. In effect,
when a person selects an activity from a shared role, and the same role has
later activities in the process flow, then have that person own the rest of the
activities for that role in that specific process. This may be desirable since this
person is familiar with the details of this specific instance.
Copyright IBM Corp. 1996, 1998
13
Ÿ If there is some front end program that uses FlowMark API calls to create and
start process instances, have it divide the work in a round robin way: one for
team A, then team B, then team C, then back to A. You can use the system
fields in the data container to limit the “range” by department, or have separate
roles whose members have the same job. For instance, instead of a role
“Clerk” for billing, you may have roles CLERKA, CLERKB, and CLERKC.
Again, you can use the data container (or use a separate but “the same”
process template).
7.1 Performance and Capacity Considerations
For every user who is assigned an activity, there is a commitment of work efforts
for FlowMark, including the actual assignment, updating the database, notifying the
user of the activity and when it changes state, and database space to maintain the
extra data. Each of these work efforts is small. However, when multiplied by many
users for many activities in many instances, the impact is significant. Weigh that
against the benefit you expect from assigning an activity to multiple users. Finally,
consider that only one user will really process the work item. Each person
assigned beyond that one adds overhead to the operation of your system.
14 FlowMark V2.3 Design Guidelines
Chapter 8. When Do I Use an Activity Block?
An activity block is a construct that allows you to group several activities together.
Its major functions are:
Ÿ To reduce clutter at a higher level. This lets you have a cleaner big picture at
upper levels of your process.
Ÿ To allow a loop. The activity block can have an exit condition, so the entire
block is repeated until particular conditions are met. This gives you a “do until”
construct for a group of activities.
Consider using a block when you have the above needs and when you have at
least three activities to include in it. You can make a single activity loop by
specifying an exit condition for the activity itself. If an activity exit condition fails,
that activity is returned (in a ready condition) to the work list of the user who
performed it.
8.1 Performance and Capacity Considerations
There is not much overhead in using an activity block. The cost incurred is for
evaluation at the beginning and end of the block itself. It differs from a subprocess
in potential database space usage. The block is always included in the instance at
the time it is created. The next section explains how a subprocess differs in this
aspect.
Copyright IBM Corp. 1996, 1998
15
16 FlowMark V2.3 Design Guidelines
Chapter 9. When Do I Use a Subprocess?
A subprocess is really just a process, but it is called by another (parent) process. It
has functions similar to an activity block, but it can do more for you. The
characteristics of a subprocess include:
Ÿ Reusability: a subprocess can be invoked at multiple points in a single process;
and it can be invoked from different processes. It is a reusable object.
Ÿ It can run as a stand-alone process.
Ÿ It can run on a separate server from its parent process, using a different
FlowMark database and different users (staff definitions). This permits you to
shift work to another server.
Ÿ It can be tested alone, allowing independent application development.
Like an activity block, a subprocess:
Ÿ Can have an exit condition, so it can repeat until specified conditions are met.
Ÿ Helps make high-level process diagrams easier to understand.
In addition to the many functions that subprocesses can serve, they can be used to
save some amount of database space, in the case where they are infrequently
used in your process flow. With such a list, there is the temptation to use them
everywhere. But you need to be careful not to overuse them, as you can
significantly alter the performance of your system.
9.1 Performance and Capacity Considerations
A subprocess affects performance and capacity. You are trading off between
processor usage and database space.
A subprocess is “late bound,” that is, not invoked until needed. There is no
database space consumed unless the subprocess is invoked. Thus, if you have a
process that includes multiple special cases or exceptions or has several possible
paths, the use of subprocesses will reduce the amount of database storage used
for a process instance. Rather than having many different activity steps loaded
when an instance is created, you can defer them so only the particular special case
(subprocess) is loaded, and then only if you need one. Depending on your
business process, this could save some amount of database space plus the
overhead to create large instances.
On the other hand, when you invoke a subprocess, the effort involved is similar to
creating a process instance. There are performance implications for creation and
deletion of the instance. See Chapter 5, “Starting and Deleting Process Instances”
on page 9 for a discussion of this.
It is worth considering the ability to run a subprocess on another FlowMark server
even if your original plans are for a single server. If you later add other servers,
you can simply update the server page in the subprocess activity notebook and
change the server (domain) where the subprocess runs.
So you need to make a decision. As in most performance and capacity decisions,
there are trade-offs. In this one, you are weighing processor usage on the server
versus space in your database. Ask yourself how frequently the particular path is
followed. If the probability is high that the function is used every time, it is better to
Copyright IBM Corp. 1996, 1998
17
leave the activities inline. If there is a low probability of needing the function, a
subprocess is preferable. Also, with subprocesses there are also the
considerations of ease of use and having a reusable object. You must make the
trade-offs.
18 FlowMark V2.3 Design Guidelines
Chapter 10. Data Container Usage
The FlowMark data container is used to pass information from activity to activity
within the process. It also controls the flow within the process when data fields are
used in transition conditions. The terminology used is “process-relevant data.” It is
important to understand this concept. The data container is not intended to be a
database. The data you specify for the data container should be specifically
needed for:
Ÿ Navigation, referenced in transition or exit conditions.
Ÿ Pointers into your enterprise databases where the application information really
exists (for example, customer number, account number, invoice number, image
folder, and document name).
Ÿ Variable information you would like to have appear in activity descriptions. This
helps users to quickly find particular activities, and can assist in limiting work
list size by Include (filtering) and Find functions.
While the data container is very useful, you need to be careful not to abuse the
concept.
All data container information is kept in the process instance in the database. It
stays there for the life of that instance. Every input and output data container
created along the way exists in the database until that instance is deleted.
Consider a somewhat extreme example. If you specified 10,000 bytes of data
container, then pass it to/from 20 activities, it appears 20 times in your FlowMark
database. It takes many times its original space since it is copied over and over,
remaining there from the time the instance is created until it is deleted. When you
multiply by the number of instances you may have in your database at peak times,
you could encounter database space problems.
Another aspect is the impact this might have on runtime client response. There is
overhead in accessing data items using the container APIs. If you have many
items, most of which are not really used in an activity but merely passed on
downstream in the process, there may be unneeded delays at the client.
10.1 Performance and Capacity Considerations
Here are some data container guidelines:
Ÿ Keep only key data in the data container. Keep application data in the
application databases and let the applications access it from there. Pass the
application the key needed to find it.
Ÿ Do not take the approach of just passing all data to every activity in the
process. Have different structures that represent the specific data needed at
different points in the process.
Ÿ Map data elements to the specific point where they are needed in the process.
Ÿ Do not use the FlowMark data containers as an application database or a data
file server.
Ÿ Use the newest container APIs for the client.
Ÿ While you should use descriptive names for data fields, do not make them
extremely long.
Copyright IBM Corp. 1996, 1998
19
20 FlowMark V2.3 Design Guidelines
Chapter 11. Using FlowMark Functions Wisely
There are many functions in FlowMark that can influence system performance but
are not directly related to process design. They relate to end-user activities. The
people who design a FlowMark system, those with the most knowledge of
FlowMark, frequently have the opportunity to influence the training the users get.
Therefore, here are some guidelines to help your users.
11.1 Sign On and Sign Off
It is best to sign on to FlowMark once a day. A signon can potentially result in the
loading of a lot of information from the server to your workstation. If you repeatedly
sign off and on, the information that is downloaded is often much the same as what
your workstation had previously. Bringing that information down again and
rebuilding your work lists and process lists creates additional system load,
additional network traffic, and delays on your workstation. When protecting a user's
worklist is a concern, consider use of a software “lockup” function to lock the
workstation when not attended.
11.2 Shut Down
Train users to close some off their windows before closing FlowMark. When a user
signs on, FlowMark tries to restore the environment to what it was when FlowMark
was shut down. If you leave FlowMark by just closing the Runtime - Icons window,
leaving not only your work list but possibly other work lists and your process list
open, that is what FlowMark will open when you next sign on. Over the course of a
day you may open many of these, but it is unlikely you would like to wait for the
server to provide all that information and the client to build all those icons and lists
first thing in the morning. It would be better to train the users to close the various
windows, except perhaps their primary work list, before closing the FlowMark
Runtime window. It will make for less system load and a quicker startup in the
morning.
11.3 Filtering Work Lists and Process Lists
In FlowMark V2.2, a new concept, “filtering at the server,” was introduced. You can
specify to the server which items in your work list or process list you wish to see.
Only those items are loaded from the server to your client workstation. Appropriate
use of this technique can significantly reduce both server resources for signon and
list refresh and client response time as well.
To use this filtering, it is important that you include it in the process design.
Filtering implies that there are things the users can specify that will allow them to
differentiate between what they want to see and what they would rather not. For
processes, the process name, process description, and category are important. For
work lists, the activity name, activity description, and process name can be used. If
you understand how your users want to classify their work, you can provide a better
design (naming conventions and inclusion of variables) for these fields, which will
help the users make use of filtering.
Copyright IBM Corp. 1996, 1998
21
To see the exact possibilities, or to help train your users, do the following, starting
from the Runtime client icons:
Ÿ For work lists, select the work list icon, then the specific work list. Open
settings, and go to the Activities page. You can do this for each work list if you
have multiples.
Ÿ For process lists, select the User information icon, then select the database,
then in the Personal data notebook, go to the Processes page.
Chapter 7, “How Many People Do I Assign to an Activity?” on page 13 talks about
long work lists. A frequent cause of long work lists is assigning each activity to
many users. We suggest that you limit how many things are assigned to each
user, where practical.
Another idea to treat carefully is “shared work lists.” Some have created artificial
users who play many or all roles in their system. This provides an overall view of
the work in the system. But it can also result in very large work lists, and anyone
accessing such a list will feel the impact of the load on the system.
Whatever the cause of long lists, you can help limit the impact. Implementing this
is a combination of process design and user training. If you design it but the users
do not use it, nothing is gained. If you do not design for it, the users will find
nothing to use. But it can have a significant positive impact, especially when there
are long work lists and process lists.
11.4 Refreshing Lists
“Refreshing” is a request to erase the copy of a list on the user's workstation and
bring a fresh copy from the server, rebuilding the list for the user. There are times
when this needs to be done, but many people doing it regularly can impact system
performance. This applies to process lists and work lists.
11.5 Using the Monitor
The FlowMark monitor function is extremely valuable in determining what is
happening in a specific process instance. But, again, a tool can be misused.
Unless you have a very good reason, do not constantly open or refresh monitors
because refreshing a process monitor (or sometimes having several displayed and
refreshing all) can put unnecessary overhead on your server. If many users
repeatedly do this, the effect is multiplied. Teach your users the great power it has,
but teach them to use it wisely,
11.6 FlowMark Bundle Activities
An advanced FlowMark function called “bundles” is described in Appendix A of IBM
FlowMark: Modeling Workflow, SH19-8241. This function allows you to
dynamically create one to n parallel activities (or activity blocks or subprocess
activities). If you use them, here are a few things to remember. The effect of the
bundle planning tool is a real-time modification of the process instance. It will
involve some amount of updating of the database. Since the resulting modification
may result in 10 or 20 parallel activities, the effect is the same (for doing staff
resolution and updating work lists) as if 10 or 20 users all completed activities at
the same time. This can be a peak in demand on the server. Also, bundles imply
22 FlowMark V2.3 Design Guidelines
arrays of data container items. The effects of large data containers was discussed
in Chapter 10, “Data Container Usage” on page 19.
Chapter 11. Using FlowMark Functions Wisely 23
24 FlowMark V2.3 Design Guidelines
Appendix A. Factors Influencing the Size of a FlowMark Data
Base
When you design your process in FlowMark Buildtime, you create a process model.
You then translate this model and create a process template. This is a bit like
compiling a program. The template contains the rules and other information
necessary to run an instance of the process. You will likely have many instances
of each process template active in FlowMark at any point in time. While all
instances that were started with a particular template will use that one single
template (it is not duplicated), there is a certain amount of information in the
database for each unique instance. Some is there because it can be altered by the
user, and some is there based on things happening dynamically as each instance
follows its particular path through the process template.
Since these things will influence the size of your database, it may help to
understand what some of them are. You will see that many have already been
mentioned throughout this redbook.
A.1 Activity Name and Description
While you may think of these two items as fixed, since you specify them when you
define the process, they are actually dynamic (or can be), so copies are kept for
each instance.
If you provide a description of the activity on the general page of the activity
notebook, you can include in it the contents of variables from the input data
container. This is often done because it helps convey information from previous
activities directly to users' work lists, helping them understand more about the
activity or instance, and allowing them to better choose which activity to work on.
Users can alter both the activity name and the description. They do this from their
work list, selecting the activity and its settings and then going to the General page
of the notebook. They might do this to make note of something that kept them
from completing the activity or to pass information on to others who have that
activity on their work list as well.
The point is that for each activity in each instance, copies of the activity name and
description are kept in the database. The bigger you make these (and description
can be up to 1024 characters), the more space will be taken in the data base.
Remember the guideline that it is important to understand how many times
something occurs. To take an extreme example, if you filled all 1024 characters in
the description of every one of 50 activities in a process and then had 2000
instances in the database, how much space is that?
1ð24 ᑍ 5ð ᑍ 2ððð = 1ðð,ððð KB
And that does not count what FlowMark and the database would require just to
keep track of it. As always, use the function when it helps you, but do not misuse
it. Constant information is better put on the Documentation page of the activity
notebook. Only one copy is kept of that, in the translated template, no matter how
many instances.
Copyright IBM Corp. 1996, 1998
25
A.2 Results of Staff Resolution
When FlowMark determines that a particular activity should be run, it goes through
a function called staff resolution. This function determines who should have this
activity as "ready" on their work list. Based on what the process designer has
specified on the two "staff" pages in the activity notebook, such as role,
organization, and skill level, FlowMark determines all the people who should see
this, includes that in the dynamic instance information, and adds it to the database
copy of the users' work list. As you can see, the more people an activity is
assigned to and the more items a person has on his work list, the more space is
required for the database.
A.3 Data Containers
We discussed this in Chapter 10, “Data Container Usage” on page 19. As
FlowMark navigates through the process, your application programs add data to
output data containers. This data is then copied into one or more input containers,
as defined in the data mapping of your process model. The number of fields and
the size of the data provided for string fields, as well as the number of input and
output containers, will help determine the necessary space in the database for each
instance. Since the container creation is dynamic, the containers exist and are
filled only when the process flows down the path where they are defined. For
paths not taken in a particular instance (called dead paths), no containers are
created.
A.4 Other Things
The items mentioned above are the major factors in determining the size of an
instance. But there are others. As mentioned earlier, the use of a subprocess
results in another process instance being created when it is encountered in the
process flow. Bundle activities result in real-time updates (additions) to the
database. And the notification server, if used, can add to the database contents.
26 FlowMark V2.3 Design Guidelines
Appendix B. The FlowMark Internet Site
If you would like more information on FlowMark, visit the Internet site:
Here you will find lots of information on what is happening in the world of
FlowMark, frequently updated.
Copyright IBM Corp. 1996, 1998
27
28 FlowMark V2.3 Design Guidelines
Appendix C. Special Notices
This publication was written to give system architects more information to plan for
the number of servers needed for their FlowMark system, and to design it for better
performance. The information in this publication is not intended as the specification
of any programming interfaces that are provided by FlowMark. See the
PUBLICATIONS section of the IBM Programming Announcement for IBM FlowMark
for more information about what publications are considered to be product
documentation.
References in this publication to IBM products, programs or services do not imply
that IBM intends to make these available in all countries in which IBM operates.
Any reference to an IBM product, program, or service is not intended to state or
imply that only IBM's product, program, or service may be used. Any functionally
equivalent program that does not infringe any of IBM's intellectual property rights
may be used instead of the IBM product, program or service.
Information in this book was developed in conjunction with use of the equipment
specified, and is limited in application to those specific hardware and software
products and levels.
IBM may have patents or pending patent applications covering subject matter in
this document. The furnishing of this document does not give you any license to
these patents. You can send license inquiries, in writing, to the IBM Director of
Licensing, IBM Corporation, 500 Columbus Avenue, Thornwood, NY 10594 USA.
Licensees of this program who wish to have information about it for the purpose of
enabling: (i) the exchange of information between independently created programs
and other programs (including this one) and (ii) the mutual use of the information
which has been exchanged, should contact IBM Corporation, Dept. 600A, Mail Drop
1329, Somers, NY 10589 USA.
Such information may be available, subject to appropriate terms and conditions,
including in some cases, payment of a fee.
The information contained in this document has not been submitted to any formal
IBM test and is distributed AS IS. The use of this information or the implementation
of any of these techniques is a customer responsibility and depends on the
customer's ability to evaluate and integrate them into the customer's operational
environment. While each item may have been reviewed by IBM for accuracy in a
specific situation, there is no guarantee that the same or similar results will be
obtained elsewhere. Customers attempting to adapt these techniques to their own
environments do so at their own risk.
Any pointers in this publication to external Web sites are provided for convenience
only and do not in any manner serve as an endorsement of these Web sites.
Any performance data contained in this document was determined in a controlled
environment, and therefore, the results that may be obtained in other operating
environments may vary significantly. Users of this document should verify the
applicable data for their specific environment.
Copyright IBM Corp. 1996, 1998
29
The following terms are trademarks of the International Business Machines
Corporation in the United States and/or other countries:
AIX
AIX/6000
DB2
IBM
OS/2
FlowMark
Operating System/2
The following terms are trademarks of other companies:
C-bus is a trademark of Corollary, Inc.
Java and HotJava are trademarks of Sun Microsystems, Incorporated.
Microsoft, Windows, Windows NT, and the Windows 95 logo are trademarks
or registered trademarks of Microsoft Corporation.
PC Direct is a trademark of Ziff Communications Company and is used
by IBM Corporation under license.
Pentium, MMX, ProShare, LANDesk, and ActionMedia are trademarks or
registered trademarks of Intel Corporation in the U.S. and other
countries.
UNIX is a registered trademark in the United States and other
countries licensed exclusively through X/Open Company Limited.
Other company, product, and service names may be trademarks or
service marks of others.
30 FlowMark V2.3 Design Guidelines
Appendix D. Related Publications
The publications listed in this section are considered particularly suitable for a more
detailed discussion of the topics covered in this redbook.
D.1 International Technical Support Organization Publications
For information on ordering these ITSO publications see “How to Get ITSO
Redbooks” on page 33.
Ÿ FlowMark Installation and Administration, SG24-4614
Ÿ FlowMark and VisualInfo with Windows, SG24-4712
Ÿ Integrating VisualAge Generator and FlowMark, SG24-4239
Ÿ Integrating IBM FlowMark with Lotus Notes, SG24-4851
Ÿ Sample Applications for FlowMark, SG24-2184
D.2 Redbooks on CD-ROMs
Redbooks are also available on CD-ROMs. Order a subscription and receive
updates 2-4 times a year at significant savings.
CD-ROM Title
Subscription
Number
Collection Kit
Number
System/390 Redbooks Collection
SBOF-7201
SBOF-7370
SBOF-7240
SBOF-6899
SBOF-6898
SBOF-7270
SBOF-7230
SBOF-7205
SBOF-8700
SBOF-7290
SK2T-2177
SK2T-6022
SK2T-8038
SK2T-8039
SK2T-8044
SK2T-2849
SK2T-8040
SK2T-8041
SK2T-8043
SK2T-8037
Networking and Systems Management Redbooks Collection
Transaction Processing and Data Management Redbook
Lotus Redbooks Collection
Tivoli Redbooks Collection
AS/400 Redbooks Collection
RS/6000 Redbooks Collection (HTML, BkMgr)
RS/6000 Redbooks Collection (PostScript)
RS/6000 Redbooks Collection (PDF Format)
Application Development Redbooks Collection
D.3 Other Publications
These publications are also relevant as further information sources:
Ÿ IBM FlowMark: Modeling Workflow, SH19-8241
Ÿ IBM FlowMark: Managing Your Workflow, SH19-8243
Ÿ IBM FlowMark: Programming Guide, SH19-8240
Ÿ IBM FlowMark: Installation and Maintenance, SH12-6260
Ÿ IBM FlowMark: Application Integration Guide, SH12-6267
Ÿ IBM FlowMark: Diagnosis Guide, SH19-8239
Copyright IBM Corp. 1996, 1998
31
32 FlowMark V2.3 Design Guidelines
How to Get ITSO Redbooks
This section explains how both customers and IBM employees can find out about ITSO redbooks, CD-ROMs,
workshops, and residencies. A form for ordering books and CD-ROMs is also provided.
This information was current at the time of publication, but is continually subject to change. The latest information
How IBM Employees Can Get ITSO Redbooks
Employees may request ITSO deliverables (redbooks, BookManager BOOKs, and CD-ROMs) and information about
redbooks, workshops, and residencies in the following ways:
Ÿ PUBORDER — to order hardcopies in United States
Ÿ GOPHER link to the Internet - type GOPHER.WTSCPOK.ITSO.IBM.COM
Ÿ Tools disks
To get LIST3820s of redbooks, type one of the following commands:
TOOLS SENDTO EHONE4 TOOLS2 REDPRINT GET SG24xxxx PACKAGE
TOOLS SENDTO CANVM2 TOOLS REDPRINT GET SG24xxxx PACKAGE (Canadian users only)
To get BookManager BOOKs of redbooks, type the following command:
TOOLCAT REDBOOKS
To get lists of redbooks, type the following command:
TOOLS SENDTO USDIST MKTTOOLS MKTTOOLS GET ITSOCAT TXT
To register for information on workshops, residencies, and redbooks, type the following command:
TOOLS SENDTO WTSCPOK TOOLS ZDISK GET ITSOREGI 1998
For a list of product area specialists in the ITSO: type the following command:
TOOLS SENDTO WTSCPOK TOOLS ZDISK GET ORGCARD PACKAGE
Ÿ Redbooks Web Site on the World Wide Web
Ÿ IBM Direct Publications Catalog on the World Wide Web
IBM employees may obtain LIST3820s of redbooks from this page.
Ÿ REDBOOKS category on INEWS
Ÿ Online — send orders to: USIB6FPL at IBMMAIL or DKIBMBSH at IBMMAIL
Ÿ Internet Listserver
With an Internet e-mail address, anyone can subscribe to an IBM Announcement Listserver. To initiate the
note (leave the subject line blank). A category form and detailed instructions will be sent to you.
Redpieces
For information so current it is still in the process of being written, look at "Redpieces" on the Redbooks Web Site
(http://www.redbooks.ibm.com/redpieces.html). Redpieces are redbooks in progress; not all redbooks become
redpieces, and sometimes just a few chapters will be published this way. The intent is to get the information out
much quicker than the formal publishing process allows.
Copyright IBM Corp. 1996, 1998
33
How Customers Can Get ITSO Redbooks
Customers may request ITSO deliverables (redbooks, BookManager BOOKs, and CD-ROMs) and information about
redbooks, workshops, and residencies in the following ways:
Ÿ Online Orders — send orders to:
IBMMAIL
Internet
In United States:
In Canada:
Outside North America:
usib6fpl at ibmmail
caibmbkz at ibmmail
dkibmbsh at ibmmail
Ÿ Telephone orders
United States (toll free)
Canada (toll free)
1-800-879-2755
1-800-IBM-4YOU
Outside North America
(long distance charges apply)
(+45) 4810-1020 - German
(+45) 4810-1620 - Italian
(+45) 4810-1270 - Norwegian
(+45) 4810-1120 - Spanish
(+45) 4810-1170 - Swedish
(+45) 4810-1320 - Danish
(+45) 4810-1420 - Dutch
(+45) 4810-1540 - English
(+45) 4810-1670 - Finnish
(+45) 4810-1220 - French
Ÿ Mail Orders — send orders to:
IBM Publications
Publications Customer Support
P.O. Box 29570
Raleigh, NC 27626-0570
USA
IBM Publications
144-4th Avenue, S.W.
Calgary, Alberta T2P 3N5
Canada
IBM Direct Services
Sortemosevej 21
DK-3450 Allerød
Denmark
Ÿ Fax — send orders to:
United States (toll free)
Canada
1-800-445-9269
1-403-267-4455
Outside North America
(+45) 48 14 2207 (long distance charge)
Ÿ 1-800-IBM-4FAX (United States) or (+1)001-408-256-5422 (Outside USA) — ask for:
Index # 4421 Abstracts of new redbooks
Index # 4422 IBM redbooks
Index # 4420 Redbooks for last six months
Ÿ On the World Wide Web
Redbooks Web Site
IBM Direct Publications Catalog
Ÿ Internet Listserver
With an Internet e-mail address, anyone can subscribe to an IBM Announcement Listserver. To initiate the
note (leave the subject line blank).
Redpieces
For information so current it is still in the process of being written, look at "Redpieces" on the Redbooks Web Site
(http://www.redbooks.ibm.com/redpieces.html). Redpieces are redbooks in progress; not all redbooks become
redpieces, and sometimes just a few chapters will be published this way. The intent is to get the information out
much quicker than the formal publishing process allows.
34 FlowMark V2.3 Design Guidelines
IBM Redbook Order Form
Please send me the following:
Title
Order Number
Quantity
First name
Company
Address
City
Last name
Postal code
Country
VAT number
Telephone number
Telefax number
Ø Invoice to customer number
Ø Credit card number
Credit card expiration date
Card issued to
Signature
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not
available in all countries. Signature mandatory for credit card payment.
How to Get ITSO Redbooks 35
36 FlowMark V2.3 Design Guidelines
Glossary
Note: This glossary defines terms and abbreviations
for IBM FlowMark. For more information about
the differences and other terms, not defined
here, refer to the respective publication as listed
in Appendix D, “Related Publications” on
page 31.
environments, such as Internet, Host communications,
and LANs. FlowMark uses either APPC or TCP/IP.
See also TCP/IP.
application development models. Process and data
models required for application systems development.
application program interface (API). An interface
provided by the workflow manager that enables
programs to be started, processes to be controlled, and
operators to work with data containers.
A
activity. A unit of work that is performed by one
person in one place and at one time. An activity
consumes time and resources and has a defined
duration with an explicit start and end time.
In LOVEM-ProModeler: on a PLOVC or JLOVC, an
activity is a manual process path component, which
receives input from an upstream component, acts upon
it, and sends output to a downstream component.
Activities can be added to manual bands.
architecture line of visibility chart (ALOVC). The
graphical representation of the essential customer and
enterprise processes and key data needs and their
main characteristics arranged in sequence. See also
enterprise architecture.
As Is. The current state of a process or process path.
See also To Be.
In FlowMark: an activity is one of the steps that make
up a process. See also program activity and process
activity.
As Is view. A chart or diagram showing the current
state of a process or process path. See also To Be
view.
activity block. In FlowMark: a modeling construct that
enables the grouping of related activities into a
lower-level diagram. It also enables the modeling of
loops and bundles. See also activity bundle.
assumptions/issues/recommendations (AIR). In
LOVEM-ProModeler: a business control parameter that
can contain assumptions, issues, and
recommendations.
activity bundle. In FlowMark: a type of activity block
that supports multiple instances of a single program or
process activity during run-time. The number of
instances of an activity is determined during run-time by
a special program activity called the planning activity.
See also planning activity.
attribute. The characteristic or property that defines an
entity, such as the attribute of a unit of information.
See also representative attribute.
audit trail. A facility for recording events that occur
when process instances are run.
AIF. Application Integration Feature: a CICS/ESA
product which helps you integrate your existing
applications without writing any code. Applications
communicate across platforms using MQSeries for
MVS/ESA, which keeps them insulated from network
complexities.
automation band. The horizontal section on a PLOVC
or JLOVC that contains systems, system functions, or
computer data stores.
Automation Manager. The Automation Manager is
responsible for connection of remote clients to OLE
servers.
AIR. See assumptions/issues/recommendations.
AIX. Advanced Interactive Executive (UNIX)
ALOVC. See architecture line of visibility chart.
B
band. The horizontal sections of an LOVC. Examples
of bands:
animation. A facility for dynamically verifying workflow
models. Animating a workflow model lets the user
simulate the flow of work through its activities.
Ÿ Customer band
Ÿ Internal/external organization band
Ÿ Internal business area or department and job bands
Ÿ Manual/automation band
API. See application program interface.
Ÿ Automation band
APPC. Advanced program-to-program communication.
A commonly used protocol for various network
Copyright IBM Corp. 1996, 1998
37
bar code. Industry standard pattern of vertical lines.
You can use bar codes to indicate the beginning of a
new folder, the beginning of a new document, or to
provide a value to be used in indexing the folder or the
document.
bus. A term borrowed from electrical engineering (or
computer design), which signifies a continuum with
concrete contact (start and exit) points. In this manual, it
represents a continuum of repetitive and unpredictable
processes, a set of sequential data stores, or a
continuum for capturing critical process quality
measurement points.
base product. The product that provides the
functionality required for the operation, for example,
FlowMark, Lotus Notes. This is the product called via
the Service Broker Manager.
business. An entity that engages in commerce. A
business produces or sells goods and services, has
goals, processes, and personnel.
benchmarking. Comparing something with a standard,
like comparing the performance of a business process
with another process of the same kind.
business area. Part of an enterprise implementing a
group or processes that support one aspect of
furthering the mission of the enterprise. Business area
is part of the logical model (LLOVC).
best of breed (BOB). A company that offers the same
or similar products and services as other companies in
that category, but at higher levels of performance in one
or more area of competition (for example, price, quality,
competence, customer service, and so on).
business control parameter. Goals, predictions,
targets, observations, and measurements of the
enterprise or individual organization units, such as
CSFs, AIRs, and CMPs. These business objects are of
primary importance to the purpose of the enterprise and
can be assigned to processes and activities in logical
and physical models and blueprints.
block. See activity block.
blueprint. The exact graphical representation of As Is
business processes or To Be designs. A blueprint can
be created at the architecture, logical, physical, or job
level. It can be used for implementing new processes
and for ongoing process management.
business process. See process.
business process management (BPM). The ongoing
management of business processes, from day-to-day
operational process management to radical business
process re-engineering.
blueprinting. The procedure used to document a
company's process design in graphical form using
ALOVCs, LLOVCs, PLOVCs, or JLOVCs.
business process modeler (BPM). An IBM business
modeling tool that is based on IBM LOVEM. Short
name: ProModeler.
BOB. See best of breed.
bottom-up. Starting the modeling or design of
business processes from their lowest level of
abstraction and detail and then integrating lower-level
models or designs into a higher-level whole. See also
top-down.
business process re-engineering (BPR). A
disciplined approach to radically changing business
processes.
C
BPM. See business process management and
business process modeler.
CABE. Computer Aided Business Engineering.
BPR. See business process re-engineering.
call flow management. The automated management
of telephone calls; especially applicable for call center
applications, where phone calls are treated as units of
work and are tracked and measured.
Buildtime. In FlowMark: the component used to define
processes. See also Runtime.
bundle. In FlowMark: a type of block that supports
multiple instances of a single program or process
activity at run time. The number of instances of the
activity is determined at run time by a special program
activity called the planning activity. See also bundle
activity, pattern activity, and planning activity.
cardinality. In data modeling: an attribute of a
relationship that describes the membership quantity.
There are four types of cardinality:
1. One-to-one
2. One-to-many
3. Many-to-many
4. Many-to-one
bundle activity. In FlowMark: one of the multiple
instances of the pattern activity created for an activity
bundle during Runtime. The number of instances is
determined by the input to the planning activity. See
also planning activity and pattern activity.
CASE. Computer Aided Software Engineering.
38 FlowMark V2.3 Design Guidelines
change management bus. On the ALOVC, a
continuum of repetitive and unpredictable processes for
enabling customers to request and affect changes (for
example, a proposal, a contract, or an order at any time
during the relationship).
critical measurement point. Any point on the process
path or within a job that is of critical importance, and
where a measurement should be taken. Measurements
can be in units of time or quantity, for example, time to
answer a customer inquiry, cycle time, number of
invoices per unit of time, error rate, and so on.
child organization. In FlowMark: an organization
within the hierarchy of administrative units of an
enterprise that has a parent organization. Each child
organization can have one parent organization and
several child organizations. The parent is one level
above in the hierarchy. See also parent organization.
critical path. Taking into account all the dependencies
and processing requirements for achieving a major goal
or target, the critical path is that sequence of events
that takes the longest time to reach the final goal.
critical success factor (CSF). A qualitative or
quantitative measure that defines the quality or
performance of an enterprise, a process path, or a job,
such as the required skills of employees to perform a
certain task. A measurable internal or external
business result that has a major influence on whether or
not an enterprise achieves its goals. CSFs can be
assigned at the following levels:
CICS/ESA. IBM Customer Information Control
System/Enterprise Systems Architecture.
common specification language. A means of
communicating across various functions, organizational
units, or levels of management in a precise language
using graphical representations, such as the four types
of LOVCs.
Ÿ The entire industry
Ÿ The enterprise
Ÿ An organizational unit, such as a business area,
department, or job
computer data store. A business object representing
computer files, databases, or other media that store
information.
Ÿ Individuals, such as managers or employees
condition. In FlowMark: an expression that determines
the flow of control through a process instance. See
also start condition, exit condition, and transition
condition.
CSD. Corrective Service Diskette (software updates for
OS/2 programs).
CUA. Common User Access.
connector. An arrow drawn between two nodes in a
process diagram to signify the flow of control or data.
See also data flow, information flow, material flow,
control flow, control connector, data connector, and
default connector.
customer. A person or business that acquires
products or services from an enterprise.
customer activity. In physical models or blueprints, it
depicts the activities performed by customers. A
customer activity can start or end a chain of activities.
constrained. Pertaining to, or characteristic of, the
PLOVC and JLOVC. Representative of the factors that
define how a process path or job is performed and by
whom (for example, time, money, organization, and
technology are constraining factors).
customer expectation. A description of what a
customer needs or wants. This can be in terms of
products, services, or the performance of an activity or
a system.
container. See data container.
customer process. On logical models or blueprints, it
depicts the actions or processes carried out by
customers.
control connector. In FlowMark: the graphical
representation of the flow of control from one activity or
block to another. See also control flow, data connector,
and default connector and transition condition.
customer satisfaction. The goal of a
customer-oriented business. Customer satisfaction
occurs when a customer receives as much as, or more
than, expected from a product or service. It is usually
measured as the number of satisfied customers as a
percentage of the total number of customers. Customer
satisfaction can be graphically shown on LOVCs by an
icon indicating whether a customer is happy or unhappy
with the operations and results of an activity.
control flow. In LOVEM: on PLOVCs and JLOVCs, a
trigger that is generated by an activity. It shows the
flow of control from one activity or task to another,
provided the transition condition, if specified, is true.
See also information flow and material flow.
In process-based applications: a control flow can
consist of a workflow, a task flow, and an event flow.
See also workflow, task flow, and event flow.
cycle time. The time it takes to complete a process
path. For example, for the order fulfillment process, the
cycle time is the time it takes to fulfill an order (from
Glossary 39
when a customer places an order to when the customer
receives the product).
default connector. In FlowMark: the graphical
representation of a special kind of control connector,
shown as in a process diagram. Control flows along
this connector if no other control path is valid. See also
connector, control connector, and transition condition.
D
DASD. Direct Access Storage Device. A device in
which access time is effectively independent of the
location of the data.
department. A subdivision of an enterprise that shows
reporting lines and performs one or more activities.
Department is part of the physical models, such as
PLOVC or HSD.
data bus. On an ALOVC or a LLOVC, a logical set of
data. A logical, dynamic data store. It Starts at the
beginning of a logical model, such as ALOVC and
LLOVC and continues until the end of the model. It
reflects the most current data at any point in a
design point. The primary focus of a design; for
example, the customer, or a workflow solution.
designing. The creative process used to plan, sketch,
and model the new business processes, process paths,
and jobs in order to create a set of detailed blueprints
from which the new design can be implemented.
relationship with a customer. Examples of data buses:
Ÿ Contact or customer data bus
Ÿ Offering or products and services data bus
Ÿ Promise or order and contract data bus
DLL. Dynamic link library. A module containing a
routine that is linked at load time or run time. FlowMark
uses the *.DLL filetype under OS/2 as well as under MS
Windows.
data component. A packet of data with which a
process deals.
data connector. In FlowMark: the graphical
representation of the flow of data in a process diagram.
See also data flow, information flow, control connector,
and default connector.
document. A transmission medium for, or depository
of, information, such as a report or an invoice.
document flow. The flow of documents through an
organizations. This can be through a document
management system in digitized form or in hardcopy
form.
data container. In FlowMark: storage for the input and
output of an activity, a block, or a process. See also
input container and output container.
document storage. A physical data store where
hard-copy documents are stored. Can be part of the
physical models or blueprints, such as PLOVC and
JLOVC. See also data store.
data dependency. Data that a process requires to
proceed. An upstream data dependency is data
required from the preceding process. A downstream
data dependency is data required by the next process.
downstream. Subsequent processes or activities, for
example the distribute process is downstream from the
order process. See also data dependency and
upstream.
data entity. See entity.
data flow. A packet of data in motion. It can consist
of data groups, data entities, and data elements. A
data flow identifies the data that is either generated
from or required by, the customer or internal processes
to which it is connected. See also information flow.
E
enterprise. An organization, usually comprised of
several lines of business, whose purpose it is to
perform a mission and to achieve goals by working with
customers and suppliers.
data store. A logical set of data or a physical place
where you can keep information (desks, filing cabinets,
databases, and personal computer files are examples of
physical data stores).
enterprise architecture. A business process
architecture at the enterprise level as expressed
through an ALOVC. It is at the logical, unconstrained
level and shows the essential process and data needs
in sequential form. See also architecture line of visibility
chart (ALOVC).
DB2/2. IBM Database 2 for OS/2, a relational
database manager.
DDE. Dynamic data exchange. An OS/2 or Microsoft
Windows feature that enables data exchange between
applications.
enterprise process. The actions or processes
performed by the enterprise.
decomposition. The process of breaking a large entity
into smaller components. For example, a process can
be decomposed into subprocesses, or an activity into
tasks.
40 FlowMark V2.3 Design Guidelines
entity. A thing or object of importance to a business
about which the business wants to keep information,
such as customer or product.
Ÿ Individuals, such as managers or employees
H
event flow. In process-based applications, including
FlowMark, an event flow is part of the control flow. It
triggers the continuation of activities that are in a wait
status. See also control flow, workflow, and task flow.
hand-off. The passing of a product, information, or
other materials from one department or workstation to
another.
hierarchical structure diagram (HSD). A graphical
modeling technique, which shows the hierarchical
structure of organizations, processes, activities, goals,
CSFs, and systems. Its major use is the systematic
refinement of objects.
exit condition. A control setting for an activity of a
PLOVC or JLOVC that determines when an activity is
complete and control is passed to the next activity. It
also determines when a process path or workflow is
completed. See also start condition, start criteria, and
exit criteria.
HLLAPI. High-level language application program
interface. HLLAPI is used by application programs for
host communication. FlowMark makes use of the
HLLAPI building block under OS/2 or MS Windows.
exit criteria. The conditions that determine when an
activity has completed its actions. See also start
criteria.
HSD. See hierarchical structure diagram.
external organization. In a PLOVC or JLOVC, an
organization unit, such as a government agency, a
bank, or a supplier, that is part of a process path, but
outside the organization of the enterprise.
I
IBM LOVEM. An IBM business process engineering or
re-engineering methodology, which can be applied at
the following levels:
F
FDL. See FlowMark Definition Language.
Ÿ Enterprise architecture
Ÿ Logical process path model or blueprint
Ÿ Physical process path model or blueprint
Ÿ Job model or blueprint
FlowMark. An IBM program product that manages and
controls the execution of a process path or workflow.
Note: There are two levels of IBM LOVEM:
FlowMark Definition Language (FDL). An external
format for defining staff, programs, data structures, and
workflow models in a flat file. The definitions in the FDL
file can then be imported into a FlowMark database.
1. Line of Visibility Engineering Methodology
This level contains the full methodology,
which is documented in the IBM LOVEM
Consultant's Guide, and which is only
available to IBM consultants.
FRL. FlowMark Runtime Language. An external
format for templates, instances, and work items in a flat
file. The export utility program EXMPFREX.EXE
located on the FlowMark database server exports the
runtime database to an FRL file. Using the import utility
program EXMPFRIM.EXE, an FRL file can be imported
into a FlowMark runtime database.
2. Line of Visibility Enterprise Modeling
This level contains the graphics and
applications of the methodology that are
implemented in ProModeler. This level is
documented in the IBM LOVEM User's
Guide and is available to the general public.
formalism. The strict attention to rules and symbols
(for example, the LOVC rules and symbols).
icon. A picture that represents the actual image of
information flow media or means of transportation, such
as a telephone, truck, or computer terminal.
G
goal. The statement of an enterprise's objectives or
direction. A business target that is to be met within a
given time. Goals can be qualitative, such as to
become the best-of-breed, or quantitative, such as to
increase revenue by 20% over the next 12 months.
Goals exist at the following organizational levels:
information. Facts or objects that have meaning to
human beings; as opposed to data, which requires
context and interpretation in order to become
information. Information is formatted data. Business
objects that are produced by or moved between
activities and systems using information flows.
Ÿ The enterprise
Ÿ An organizational unit, such as a business area,
department, or job
information flow. An ordered packet of data. Input to,
or output from, any object on a PLOVC, or JLOVC,
Glossary 41
such as an order, a shipping document, or an invoice.
Information flows can use various media, such as FAX
machines, telephones, or electronic mail, which can be
represented on the LOVCs by icons. See also data
flow, material flow, and control flow.
between your customer and internal processes or
activities where all points of contact (service
encounters) are shown. See also service encounter.
line of visibility chart (LOVC). The graphical
representation of all aspects of your business processes
that are required to provide your customer with a
specific product or service. It shows all points of
contact with your customer. The LOVC is implemented
in four different types of charts:
information system. See system.
input container. In FlowMark: storage for data used
as an input for activities, processes, or blocks. See
also output container.
Ÿ ALOVC. See architecture line of visibility chart.
Ÿ LLOVC. See logical line of visibility chart.
Ÿ PLOVC. See physical line of visibility chart.
Ÿ JLOVC. See job line of visibility chart.
inquiry management bus. On the ALOVC, a
continuum of repetitive and unpredictable processes for
enabling customers to request information on anything
about the company, its products and services, or a past
service encounter (for example, an inquiry about a
proposal, a contract, or an order). See also bus and
change management bus.
Line of Visibility Engineering Methodology
(LOVEM). See IBM LOVEM.
Line of Visibility Enterprise Modeling (LOVEM). See
IBM LOVEM.
internal interface. An interface between two internal
business functions, departments, or jobs where a
dependency exists or a transfer takes place.
LLOVC. See logical line of visibility chart.
load balancing. Attempting to ensure that each
worker gets the same amount of work to perform. Can
be automated or manual.
issue. A matter at dispute that needs to be discussed
and resolved.
LOB. See line of business.
J
location. A physical place where activities are
performed or where information or materials are stored.
JLOVC. See job line of visibility chart.
job. The physical implementation of business
logical. The abstract or generic nature of business
processes or data before any physical constraints are
applied. Logical defines what process or data is
required, not how it is implemented. See also
unconstrained.
processes, as expressed through manual activities and
interfaces with customers, systems, and internal or
external organizations. A series of one or more
activities in a department that are performed by one
employee. A job is represented by the JLOVC and can
be part of a PLOVC. Examples of a job: marketing
representative or customer service representative.
logical line of visibility chart (LLOVC). A logical
modeling or blueprinting technique that shows the
effectiveness of the process path that you are studying.
Using this technique, you focus on what needs to be
done, not how it is done. See also line of visibility
chart.
job line of visibility chart (JLOVC). A physical
modeling and blueprinting technique that shows the
effectiveness and efficiency of one particular job. Using
the JLOVC, you focus on how an individual job is or will
be implemented, and who is or will be executing the
manual activities. It also shows the relationship of each
activity to customer activities, systems, and internal or
external organizations. See also line of visibility chart.
logical model or blueprint. The depiction of the
effectiveness of a process: doing the right thing. See
also logical, model, and blueprint.
logical-to-physical transformation. The translation of
a logical process into its physical implementation
components, such as manual activities or systems
functions. See also logical transformation list.
L
LAN. Local area network.
logical transformation list (LTL). A technique for
transforming logical processes into physical
implementation scenarios. For example, a logical
process can be transformed into any number of manual
activities, any number of systems functions, or both.
line of business (LOB). A family of products or
services, having common characteristics.
line of visibility (LOV). On an LOVC, the line
42 FlowMark V2.3 Design Guidelines
loop. A loop is an iteration of activities on a PLOVC or
JLOVC. There are two sets of exit criteria for a loop:
measurement point. A designated point in a process
path where measurements are to be taken. See also
critical measurement point.
1. One set contains the criteria for exiting the loop
through the normal flow when the exit conditions
are met.
methodology. A collection of related techniques and
notations based on a common philosophy to solve a
series of major tasks. See also IBM LOVEM.
2. The other set contains the criteria for how often the
flow can go through the loop before terminating it if
the first criteria are not met. This set also has to
describe where the flow continues in case of an
abnormal termination.
metrics. The definition and description of a procedure
for taking measurements. Metrics can be assigned to
activities as actual, target, or ultimate values.
mission. The purpose and nature of an enterprise.
loop connector. A symbol on a PLOVC or JLOVC
that points back to the starting point of a loop. The loop
connector contains the short and long names of the
activity, where the loop starts.
model. The graphical and written representation of
observations and predictions of how a design could or
should be implemented. Models are usually built at
various levels of abstraction and detail. For example, a
business model depicts a defined business area that is
important to the enterprise; it can be shown as different
views of the same business area, such as:
LOV. See line of visibility.
LOVC. See line of visibility chart.
LOVEM. See IBM LOVEM.
Ÿ Process or process path
Ÿ Organization
Ÿ Performance
LTL. See logical transformation list.
modeling. Part of the design process used to create
alternatives or what if scenarios before committing to
the final design. See also model.
M
manual/automation interface. The
manual-automation line on a PLOVC or JLOVC
between manual activities and systems. Systems
placed on this line show user interactions with the
systems. Systems placed below this line are batch
systems with no direct user interaction.
moment of truth. Your customer's perception resulting
from any contact that your company has with that
customer either in person or through a document,
product, or system. See also service encounter.
MQSeries. Message Queue Series: a communications
layer that establishes connection between two systems.
With MQSeries, messages can be sent and received
through queues.
material. A commodity that is of value for the business
process. Materials are used or worked on by an activity
or system and are transported between activities and
systems. See also material flow.
material flow. Any tangible product or document that
is generated by an activity or system.
N
In LOVEM: input to, or output from, an activity or
system on a PLOVC or JLOVC; for example, a car, a
mortgage document, or a consultant's report. The
mode of transportation, such as courier, airplane, or
truck, can also be shown on the diagram as icons. See
also information flow, data flow, document flow, and
control flow.
navigation. The movement from a completed activity
to downstream activities. The paths followed are
determined by control parameters, their associated
transition conditions, and by the start conditions of
activities. See also control connector, start condition,
exit condition, and transition condition.
navigation evaluation. The process FlowMark uses to
measurement. The extent, quality, or size of an
object. For example, the measurement of the object
box can be expressed by volume, height, weight, and
the measurement of the object process can be
expressed by effectiveness, cost, duration, or maturity.
Measurements can be used for benchmarking. See
also benchmarking.
decide which path to take. See navigation.
node. A point at which one or more functional units
connect. In a process diagram, nodes are the symbols
or objects that can be joined by connectors or flows,
such as activities, systems, blocks, sources, and sinks.
Glossary 43
planning activity. In FlowMark: a special program
activity that creates, at run time, the required number of
bundle activities for a specific bundle. The planning
activity must use a program that refers, in its
registration, to the bundle-planning tool supplied with
the FlowMark product. See also program activity,
program registration, and bundle activity.
O
opportunity area (OA). A point in a process or
process path where possibilities, advantages, or other
positive factors can help an enterprise meet its goals.
organization. An administrative unit of an enterprise.
In FlowMark: organization is one of the criteria that can
be used to dynamically assign activities to people. See
also role, child organization and parent organization.
platform. The operating system environment in which
a program runs. FlowMark is a distributed,
cross-platform application, which can run on OS/2, AIX,
and Windows.
organization unit. An administrative subdivision with
reporting lines that implement processes; for example, a
department.
PLOVC. See physical line of visibility chart.
policy. A principle, plan, or course of action pursued
by an enterprise.
OS/2. IBM's Operating System/2 for workstations.
output container. In FlowMark: storage for data
produced by an activity, process, or block for use by
other activities. It can also be used for evaluation of
conditions. See also sink.
problem. An obstacle to meeting a goal or fulfilling a
CSF. A problem can also be a situation or issue that is
uncertain, complicated, or difficult to deal with.
problem area (PA). A point in a process or process
path where difficulties, constraints, or other negative
factors prevent the enterprise from meeting its goals or
CSFs.
P
parent organization. In FlowMark: an organization
within the hierarchy of administrative units of an
enterprise that has one or more child organizations. A
child is one level below its parent in the hierarchy. See
also child organization.
procedure. A series of steps or activities required to
perform a process.
process. A business function or operation that
achieves results for customers with input from suppliers.
A process transforms the nature, status, or composition
of input to produce output according to business rules
and policies. A process is a means to achieving the
goals and strategies of an enterprise. See also
subprocess.
In LOVEM-ProModeler: a process is a logical
component on an ALOVC or LLOVC.
In FlowMark: a process is a set of activities that must
be completed to accomplish a given task.
pattern activity. In FlowMark: the single program or
process activity in a bundle from which multiple
instances, called bundle activities, are created. See
also bundle activity.
PC. Personal computer or workstation.
physical. The concrete, specific, or constrained nature
of business processes and data. Physical defines the
how, where, when, or by whom a process is performed
or data is used. See also constrained.
process activity. In FlowMark: an activity to which a
separate process is assigned. Starting this activity
creates an instance of the referenced process and
starts it. See also program activity.
physical constraints. See constrained.
physical line of visibility chart (PLOVC). A business
process modeling or blueprinting technique that shows
the effectiveness and efficiency of a process path. A
PLOVC is a sequence of physical business objects,
such as activities and systems. See also physical and
line of visibility chart.
process administrator. In FlowMark: the person
responsible for the execution of a process instance. A
process administrator can be specified in the workflow
model; otherwise it is the person who starts the
process.
physical model or blueprint. The depiction of the
efficiency of a process: doing the thing right. The
physical model or blueprint shows the how, where,
when, or by whom aspects of an enterprise, such as the
resources required to perform a process or process
path. See also model, blueprint, and physical.
process category. In FlowMark: an attribute that a
process modeler specifies for a process. Only users
who are authorized for this category can start and
control instances of the process as top-level. See also
top-level process.
process cycle time. The elapsed time required to
receive, process, and forward a transaction.
44 FlowMark V2.3 Design Guidelines
process diagram. A graphical representation of a
process or process path that shows all its components.
program activity. In FlowMark: an activity to which a
registered program is assigned. Starting this activity
invokes the program. See also process activity.
process instance. In FlowMark: an executable copy
of a process template in Runtime.
program registration. In FlowMark: identification of a
program to a FlowMark database, so that it can be
assigned to a program activity in a workflow model.
See also program activity.
process management. In FlowMark: the Runtime
tasks associated with process instances, such as
creating, starting, suspending, resuming, terminating,
restarting, and deleting process instances. See also
business process management (BPM) and process path
management.
R
recommendation. Advice or suggestion on how to
meet a goal, solve a problem, evaluate a CSF, or carry
out a strategy or policy.
process manager. A manager who has the delegated
responsibility from a process owner to manage the
day-to-day operations of a process or process path.
See also process owner.
refinement. A standard modeling technique used to
view the parts of a whole in increasing amounts of
detail. See also hierarchical structure diagram (HSD).
process owner. A senior manager who is responsible
for managing all aspects of a business process or
process path. A process owner usually delegates the
operational management to process managers. See
also process manager.
relationship. A descriptive association between two
data entities or relationships in a data model.
report. Formatted text and graphics, usually generated
by a system.
process path. A sequence of processes or activities
and flows of data or information that produce a specific
product or service. A process path usually starts and
ends with a customer service encounter. See also
service encounter.
report layout. The design and specifications for the
format of a printed report. See also screen layout.
repository. An organized, shared collection of data or
information that supports business process
re-engineering, application development, or business or
systems management. It is usually automated and is
implemented as a database.
process path management. The management of a
business across the traditional vertical processes or
organizations; for example, in a traditional order
fulfillment company, the vertical processes are sell,
order, supply, distribute, settle.
REXX. Restructured extended executor language. A
procedures language.
process quality management bus. On the ALOVC, a
continuum across the enterprise process path to
capture any process quality parameters, such as CMPs,
CSFs, goals, strategies, or policies in relation to
customer service encounters. See also bus.
RISC. Reduced instruction set computer (runs AIX).
role. In FlowMark: a responsibility that is defined for
staff members. Role is one of the criteria that can be
used to dynamically assign activities to people. See
also organization.
process status. In FlowMark: the status of a process
instance. The status can be one of the following:
Ÿ Ready
root cause analysis. The analytical determination of
Ÿ Pending
Ÿ Running
Ÿ Suspended
Ÿ Terminated
Ÿ Finished
the cause of the symptom of a problem.
Runtime. In FlowMark: the component used to
execute process instances. The Runtime component
consists of:
Ÿ Runtime server
Ÿ Program execution client
Ÿ Bundle server
process template. In FlowMark: the translated form of
a workflow model in Runtime.
Ÿ Notification service
Ÿ Delivery server
Ÿ Runtime client
program. In FlowMark: a computer-based application
that supports the work to be done in an activity.
Program activities reference executable programs using
the logical names associated with the programs in
FlowMark program registrations. See also program
registration.
See also Buildtime and Runtime client.
Glossary 45
Runtime client. In FlowMark: the user interface for
working with process templates, process instances,
work lists, and work items. See also Runtime.
subject expert. A specialist in a particular area of
expertise, such as workflow management.
subprocess. A lower level process. Processes can
be refined into subprocesses through the HSD modeling
techniques. See also hierarchical structure diagram
(HSD) and process.
In FlowMark: a process instance that is started by a
process activity.
S
screen layout. The design and specifications of the
image that the user sees on the screen of a system.
See also report layout.
substitute. In FlowMark: the person to whom an
activity is automatically transferred if the person to
whom the activity is assigned is flagged as absent.
service encounter. Any point of contact with your
customer. See also moment of truth.
shredder. A machine for the destruction of documents.
symbol. A graphical representation of an object or
thing, which may be abstract in nature; for example, a
line with an arrow is the symbol for a data or
information flow.
simulation. A mock-up version or prototype of the new
process and job design used to test assumptions before
final implementation.
system. A set of processes with a common aim that
act on data or information using input and producing
output. Usually used in the context of information
system or data processing system.
sink. In FlowMark: the symbol that represents the
output container of an activity, process, or block. See
also output container and source.
skill. An ability, proficiency, expertness of a person
that comes from training, practice, and experience.
system development. The design, code, test,
implementation, and maintenance of an information
system. Can also denote a business function that
performs systems development.
source. In FlowMark: the symbol that represents the
input container of an activity, process, or block. See
also input container and sink.
system function. A component or module of a
system. A system can be refined into system functions
using the HSD modeling technique. See also
hierarchical structure diagram (HSD) and system.
staff. In FlowMark: the people (and their roles,
organizations, and levels) who execute the process
instances. Staff is defined in a FlowMark database.
See also role and organization.
T
staff resolution. The process FlowMark uses to
decide which worklists to add a process to.
task. The lowest level of activity or unit of work.
Tasks belong to the physical business models. There is
no implied sequence or order in performing tasks within
an activity. Activities can be refined into tasks using the
HSD modeling technique. See also hierarchical
structure diagram (HSD) and activity.
start activity. In FlowMark: an activity that has no
incoming control connector. A start activity becomes
ready when the process or block that contains it starts.
There can be more than one start activity in a process
or block.
task flow. In process-based applications, a task flow is
part of a control flow. See also control flow, workflow,
event flow, and document flow.
start condition. A control setting that determines
when an activity with incoming control connectors can
start. It also determines when a process path or
workflow can start. See also condition, exit condition,
and transition condition.
TCP/IP. Transmission control protocol/Internet
protocol. A commonly used protocol for various
network environments, such as Internet, Host
communications, and LANs. FlowMark uses either
TCP/IP or APPC. See also APPC.
start criteria. A control setting for activities on
PLOVCs or JLOVCs that determines when an activity or
a process path can start. See also exit criteria.
technique. A procedure for doing anything in an
orderly way; a method.
strategy. A pattern of goals, policies, and plans that
specify how an enterprise is to function over a given
period of time. A strategy can specify areas for product
development and marketing as well as techniques for
responding to competition.
time line. A notation on the PLOVC and the JLOVC
that shows the time between individual activities as well
as for the entire process path or job; for example, the
46 FlowMark V2.3 Design Guidelines
order cycle time. The time line shows both actual (As
Is) and target (To Be) times.
V
VHLPI. VisualInfo high-level programming interface.
The service broker for VisualInfo. It can be used to
integrate FlowMark with VisualInfo for document
management.
To Be. The desired state of a process or process path:
how it could be or should be. See also As Is.
To Be view. A chart or diagram showing the desired
state of a process or process path. See also As Is
view.
VisualBasic. A programming language under MS
Windows.
top-down. Modeling or designing business processes
from their most abstract level down to their most
concrete and constrained levels of detail. See also
bottom-up.
VisualInfo. An IBM product for document
management.
V2R1. Version 2 Release 1.
V2R2. Version 2 Release 2.
V2R3. Version 2 Release 3.
top-level process. In FlowMark: a process that is
started from a user's process list or from an application
program.
transition condition. In FlowMark: a logical
expression associated with a control connector. If
specified, it must be true for control to flow along the
associated control connector. See also control
connector, default connector, condition, start condition,
and exit condition.
W
WISDDM. World-wide integrated solution design and
delivery methodology. WISDDM is a set of I/T
methodologies, such as:
Ÿ The application development methodology, which is
based on:
trigger. An event or condition that starts or ends an
activity, process, or process path. See also start
condition and exit condition.
– Solution/2000
– End-to-End
– Full Life-Cycle Testing
U
– Redevelopment
– Package Selection
unconstrained. Pertaining to, or characteristic of, the
ALOVC and LLOVC techniques, or representative of the
factors that define what a process is doing not how it is
being done. See also logical.
Ÿ The project management methodology, which is
based on:
– managing implementation of the total project
– project management for project executives
– other IBM project management approaches
unit of measure. A standard dimension, extent, or
quantity, such as days, hours, or minutes; dollars or
cents; or meters or centimeters. A unit of measure is
used for measurement purposes.
workflow. A sequence of activities (units of work). A
movement of units of work through a process. In
process-based applications, it can be part of a control
flow. See also control flow, task flow, and event flow.
upstream. Preceding processes or activities; for
example, the order process is upstream from the
distribute process. See also downstream.
workflow management. The art of controlling or
administering a sequence of activities.
workflow model. In FlowMark: a complete
representation of a process. It consists of the process
diagram and settings and the definition of staff,
programs, and data structures that are associated with
the activities of a process.
work list. In FlowMark: a list of work items assigned to
a staff member.
Glossary 47
48 FlowMark V2.3 Design Guidelines
Index
A
D
activity 1, 3, 6, 7, 8, 11, 12, 13, 14, 15, 17, 19
automatic 12
data container 2, 14, 19
input 19
block 1, 15
output 19
networks
1
data elements 19
notebook 13
staff pages 13
volumes 11
data flow
data structure 2, 6
Data Structure Definition facility
1
2
activity block
activity, automatically started
2
database 3, 7, 10, 12, 13, 14, 17, 19
size
1
7
activity, unattended
additional hardware
AIX 5, 6
1
3
database space 10
definition facility, FlowMark
delete finished items
deleting 10
design 5, 11
1
9
application 1, 3, 5, 6, 7, 11, 12, 17, 19
assign
1
audit trail 3, 9
automate 11
disk I/O
6
automatic 9, 12
automatically started
E
1
end-user training 21
exception 7, 8, 12
B
example of
7
bibliography 31
Boolean expression
Buildtime 1, 2, 6
exceptions 3, 7, 11, 17
exit condition 8, 15, 17
ExmcStartProcess API
1
9
business process
automating
business processes
business requirements
7
ExmDeleteProcess API 10
ExmTerminateProcess API
7
9
1
5
F
business rules
3
filtering 19, 21
find 19
flow 1, 3
C
capacity 3, 5, 7, 10, 11, 14, 17, 19
cleanup interval 10
control
1
data
1
client 11
FlowMark
4
client response time 21
constraints
4
client workstation, no change
client/server
5
enhancements
new functions
4
4
5
communications protocol
conflicts 13
6
FlowMark API 7, 9, 14
FlowMark definition facility
frequently asked questions
1
3
connectors
1
construct 15
container
source
control flow
7
7
G
glossary 37
1
conditional
unconditional
cost 5, 15
customer 3, 7, 12, 19
design 12
1
1
H
hardware cost
5
hardware, additional
3
Copyright IBM Corp. 1996, 1998
49
headquarters 5, 6
process (continued)
design 1, 2, 3, 6, 11, 12, 13, 21
ongoing
example 8, 12, 14
example of 5, 7
exception
exceptions
3
I
impact 3, 6, 11, 14, 19, 22
include 19, 21
8
input container
instance
6
7
3
finished
flow
guidelines
9
3
7
K
instance 1, 9, 19
invoking 17
knowledge workers 11
models
1
overhead
parent 17
performance
8
L
LAN
3
3
load balancing 13
short
8
size of
7
starting
template 5, 7, 9, 12, 14
terminated
Process Definition facility
process flow
9
M
memory (swapping)
6
9
monitor
9
1
1
N
process list 21
process model
navigation 1, 19
7
navigation evaluation 11
network 13, 21
process-relevant data 19
processor utilization
program 1, 12
design 12
6
network address
nodes
6
1
notebook, personal data settings
notification servicer 10
9
programs
1
assignment of
1
O
R
off-load 10
organization 13
regional
6
resources
6
OS/2
5
response time 1, 6, 19
poor
response time, client 21
overhead 11, 14, 15, 19
6
response, runtime client 19
reusability 17
role 13
P
pass data
3
peak times 19
people
performance 3, 5, 7, 10, 11, 12, 14, 17, 19
performance capacity 15
roles
1
1
RS/6000
5
runtime client response 19
personal data notebook 22
personal data settings notebook
pointers 19
9
S
server 1, 2, 3, 5, 6, 7, 9, 10, 11, 17, 19, 21
price/performance
process 1, 2, 3, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 17,
19, 21
5
AIX
client workstation, no change
dedicated machine
Intel
multiple
5
5
6
definition
deleting
1
9
5
5
automatically
manually
9
dividing the work
independence of
5
6
9
mix of users
5
50 FlowMark V2.3 Design Guidelines
server (continued)
multiple (continued)
no communication
6
subprocess
6
OS/2
5
planning
regional
5
5
registration
2
single
5
step up
5
Unix
5
Server Definition facility
shutdown 21
signoff 21
2
signon 21
skill level 13
staff 1, 5, 13
allocation of
1
staff definitions 17
staff resolution 6, 7, 11
structure 19
subprocess 2, 5, 6, 15, 17
activity notebook 17
on another FlowMark server 17
remote
2
T
thinking 11
trade-offs 17
training, end-user 21
U
unattended
1
user
1
V
volumes, workload
3
W
work list 1, 8, 10, 11, 13, 19, 21, 22
large 22
roll 13
shared 22
work lists 13, 21
workflow 1, 4
engine
1
management
1
workload volumes
3
Index 51
52 FlowMark V2.3 Design Guidelines
ITSO Redbook Evaluation
Image and Workflow Library: FlowMark V2.3 Design Guidelines
SG24-4613-02
Your feedback is very important to help us maintain the quality of ITSO redbooks. Please complete this
questionnaire and return it using one of the following methods:
Ÿ Fax this form to: USA International Access Code + 1 914 432 8264
Ÿ Send your comments in an Internet note to [email protected]
Please rate your overall satisfaction with this book using the scale:
(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)
Overall Satisfaction
____________
Please answer the following questions:
Was this redbook published in time for your needs?
If no, please explain:
Yes____ No____
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
What other redbooks would you like to see published?
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
Comments/Suggestions:
( THANK YOU FOR YOUR FEEDBACK! )
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
_____________________________________________________________________________________________________
Copyright IBM Corp. 1996, 1998
53
Image and Workflow Library: FlowMark V2.3 Design Guidelines
SG24-4613-02
|