BPM Design Guide (IBM SW) PDF
BPM Design Guide (IBM SW) PDF
BPM Design Guide (IBM SW) PDF
Business Process
Management Design Guide
Using IBM Business Process Manager
In partnership with
Academy of Technology
Redbooks
International Technical Support Organization
April 2015
SG24-8282-00
Note: Before using this information and the product it supports, read the information in
Notices on page ix.
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Now you can become a published author, too . . . . . . . . . . . . . . . . . . . . . . . . xvii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Stay connected to IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
iv Business Process Management Design Guide: Using IBM Business Process Manager
3.3 External system of record considerations . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.3.1 Introducing an external SOR into the IBM BPM process application
solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.3.2 Business entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.3.3 IBM BPM business object model design considerations. . . . . . . . . . 92
3.3.4 Accessing existing system of records . . . . . . . . . . . . . . . . . . . . . . . . 96
3.3.5 Locking mechanism for concurrent access . . . . . . . . . . . . . . . . . . . . 97
3.3.6 Accessing reference data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.4 Integration architecture considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.4.1 Advanced Integration Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.5 Infrastructure architecture considerations . . . . . . . . . . . . . . . . . . . . . . . . 105
3.6 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Contents v
5.4.3 Data flow in Coaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
5.4.4 Integration design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
5.5 Toolkit design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
5.5.1 Categorizing library items into toolkits. . . . . . . . . . . . . . . . . . . . . . . 188
5.5.2 Toolkit maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
5.5.3 Design patterns and performance considerations. . . . . . . . . . . . . . 190
5.6 Error handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
5.6.1 Error handling concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
5.6.2 Error handling strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
5.7 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
5.8 Asset maintenance and governance considerations . . . . . . . . . . . . . . . . 205
5.8.1 Shared assets in IBM BPM Process Center . . . . . . . . . . . . . . . . . . 205
5.8.2 Managing IBM Process Designer artifacts . . . . . . . . . . . . . . . . . . . 208
5.8.3 Managing advanced artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
5.8.4 Deployment governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
5.8.5 Managing tracks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
5.9 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
vi Business Process Management Design Guide: Using IBM Business Process Manager
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Contents vii
viii Business Process Management Design Guide: Using IBM Business Process Manager
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features described in this document in other countries. Consult your
local IBM representative for information about the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not infringe
any IBM intellectual property right may be used instead. However, it is the users responsibility to evaluate and
verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not grant you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made to the
information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.
Any references in this information to non-IBM websites are provided for convenience only and do not in any
manner serve as an endorsement of those websites. The materials at those websites are not part of the materials
for this IBM product and use of those websites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any
obligation to you.
Any performance data contained herein was determined in a controlled environment. Therefore, the results
obtained in other operating environments may vary significantly. Some measurements may have been made on
development-level systems and there is no guarantee that these measurements will be the same on generally
available systems. Furthermore, some measurements may have been estimated through extrapolation. Actual
results may vary. Users of this document should verify the applicable data for their specific environment.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them as
completely as possible, the examples include the names of individuals, companies, brands, and products. All of
these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is
entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any
form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs
conforming to the application programming interface for the operating platform for which the sample programs are
written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or
imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample
programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing
application programs conforming to IBM's application programming interfaces.
x Business Process Management Design Guide: Using IBM Business Process Manager
IBM REDBOOKS PROMOTIONS
Download
Android
iOS
Now
Process owners and business owners can use this solution to engage directly in
the improvement of their business processes.
IBM BPM excels in integrating role-based process design, and provides a social
BPM experience. It enables asset sharing and creating versions through its
Process Center. The Process Center acts as a unified repository, making it
possible to manage changes to the business processes with confidence.
IBM BPM supports a wide range of standards for process modeling and
exchange. Built-in analytics and search capabilities help to further improve and
optimize the business processes.
This IBM Redbooks publication provides valuable information for project teams
and business people that are involved in projects using IBM BPM. It describes
the important design decisions that you face as a team. These decisions
invariably have an effect on the success of your project.
These decisions range from the more business-centric decisions, such as which
should be your first process, to the more technical decisions, such as solution
analysis and architectural considerations.
xiv Business Process Management Design Guide: Using IBM Business Process Manager
Magnus Borgenstrand is a Senior Technical
Engineer with IBM North America. He joined IBM
through the Lombardi acquisition in 2010 and
quickly became the go-to person for things relating
to BPM. He has over 16 years of experience
planning and implementing BPM disciplines and
solutions with global clients across many
industries. His work has taken him and his family
to North America, Europe, Asia, and Australia. His
particular emphasis has been in bringing together
both business and IT as a part of the methodology
to ensure project success. His approach is to start
with manageable projects and grow into enterprise
solutions. Magnus attended Ume University in
Sweden and has a degree in Space Engineering.
Magnus also studied Math and Computer Science
at Stockholm University.
Preface xv
J. Keith Wood is a Systems Architect and Security
Team Lead in the IBM BPM services organization
based in Austin, Texas. After more than 20 years
as a software developer and solutions architect, he
now consults with BPM clients to promote more
secured installations and environments. Before
joining IBM, Keith consulted with a wide variety of
clients in the financial services,
telecommunications, and retail sectors.
Special thanks go to Brian Petrini, Technical Product Manager IBM BPM, and
Kim Clark, IBM Certified IT Specialist SOA Foundation, for their valuable input to
the overall structure of this Redbooks Publication, and for their course covering
Integration and SOA Design.
xvi Business Process Management Design Guide: Using IBM Business Process Manager
Thanks to the following people for their contributions to this project:
Learn more about the residency program, browse the residency index, and
apply online:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us.
Preface xvii
Stay connected to IBM Redbooks
Find us on Facebook:
http://www.facebook.com/IBMRedbooks
Follow us on Twitter:
http://twitter.com/ibmredbooks
Look for us on LinkedIn:
http://www.linkedin.com/groups?home=&gid=2130806
Explore new Redbooks publications, residencies, and workshops with the
IBM Redbooks weekly newsletter:
https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm
Stay current on recent Redbooks publications with RSS Feeds:
http://www.redbooks.ibm.com/rss.html
xviii Business Process Management Design Guide: Using IBM Business Process Manager
1
We also share our experience regarding the design decisions you face, from a
business perspective, that affect the outcome of your BPM project. This chapter
is targeted at business people and project managers that are new to BPM.
1.1.1 What
First, it is important that we emphasize the following statement: BPM is not a
product or a technology. BPM is a comprehensive management approach to
managing and improving the efficiency and effectiveness of business processes
across the enterprise.
BPM enables you to manage your processes and support corporate initiatives,
such as improving product quality, reducing time-to-market, expanding to new
markets, raising client satisfaction, increasing profit margins, and so on.
The approach of BPM can be, and many times is, applied without any BPM
software. In fact, as you will see later in this chapter, the management approach
of looking at and improving your business processes are much older than the
software that supports it.
This book is mostly about the technical design decisions that affect the outcome
of implementing BPM solutions.
2 Business Process Management Design Guide: Using IBM Business Process Manager
As you will see later in this chapter, however, the success of BPM projects is not
affected only by the technical decisions that you make. Other aspects, such as
the involvement of business, aligning project goals to business outcomes, the
methodology chosen, the selection of the first process, cultural change, and so
on, also have a big effect on the success. In this first chapter we examine these
non-technical aspects.
For a more detailed description of how to adopt BPM across your organization
and ensure its success, see the IBM Redbooks publication Scaling BPM
Adoption: From Project to Program with IBM Business Process Manager,
SG24-7973.
Remember that the main objectives with any project using a BPM suite are
ultimately to gain business agility, reduce risk, save money by removing steps
that do not add value, reduce rework, automate certain steps, and so on.
Before we describe the details, though, we briefly consider the history of BPM.
He was also one of the first to push for employees to be trained and developed as
a way to improve efficiency. This was focused on training the employee to do one
thing only and do it well. Taylors work was focused on efficiency, or to put it
another way, do one thing correctly.
In the mid 1980s, Motorola introduced Six Sigma2, which is a set of techniques
and tools for process improvement. Six Sigma is focused on the improvement of
process output by removing errors and variations in processes.
Lean3 was derived from Toyota Production System in the 1990s, and is
concerned with the elimination of waste. From a business process perspective,
we analyze business processes, classify each step, and remove steps that do not
add value. This business process can lead to savings due to reduced processing
time. This approach targets the effectiveness of business processes, or to put it
another way, do the correct thing.
1 http://www.britannica.com/EBchecked/topic/584820/Frederick-W-Taylor
2
Michael George, David Rowlands, Bill Kastle, What is Lean Six Sigma? (McGraw-Hill Professional
Publishing, October 27, 2003)
3 James P. Womack, Daniel T. Jones, and Daniel Roos, The Machine That Changed the World: The
Story of Lean Production Toyota's Secret Weapon in the Global Car Wars That Is Now
Revolutionizing World Industry (Free Press, March 13, 2007)
Today, BPM suites, such as IBM BPM, are built to support organizations on their
entire BPM journey, from the smallest initial projects to enterprise-wide adoption.
A modern BPM suite covers many different aspects, including workflow, user
interfaces (UIs), reporting, data modeling, integration, and so on. Figure 1-1
shows the different aspects of a modern BPM tool.
4 Business Process Management Design Guide: Using IBM Business Process Manager
Any modern BPM suite supports the full lifecycle of continuous process
improvement. It is able to support a project through process discovery and
documentation, modeling, execution, and not least process improvement. A key
aspect is also the support of the collaborative nature of BPM, where business
people can easily be engaged. BPM supports the following phases:
Discovery phase
A key aspect of any project is process discovery, during which the business
user is involved in documenting processes. This phase is typically owned by a
business analyst who involves employees that are part of the process, or
know the process very well.
This phase of a project is very much focused on documenting and
understanding the as-is business process. After that, you look at the to-be
process model, which includes potential improvements that can be made to
the business process.
Process discovery has historically been done by having all the stakeholders
locked in a room for a few days or a week with a stack of post-it notes that is
put on the wall or on a roll of brown paper. The post-it notes are moved
around until you can agree on the correct business process. At the end of the
workshop, you document your process in a modeling tool like Microsoft Visio.
There are several issues with this approach:
To make this a collaborative effort, which is important if you want input
from everybody involved, you really need to be physically in the same
location, which can be costly for organizations that are spread across
several cities or countries.
Much manual effort needs to go into the management of all process
diagrams and their multiple versions.
You also need to manually merge different versions of a process when
somebody creates a copy to make some changes locally.
To make this phase easier and ensure the involvement of business users, it is
key that the selected tool is easy to use. It is also important that business
users can collaborate at any time, no matter where they are located. You
really want business users involved throughout the project, and not just for the
first 3 - 4 days. For ease of access and interaction, therefore, it is advised that
you use a collaborative process discovery tool, such as a cloud-based tool.
The tool should also be socially enabled, to support collaboration and help
with the organization and management of processes as you build your
enterprise process inventory. This is especially important when you take on
BPM from a broader organizational perspective, and start having several
teams or departments documenting their processes.
6 Business Process Management Design Guide: Using IBM Business Process Manager
Process improvement
One key aspect of BPM and the use of a BPM suite is that you want to be able
to improve your processes by first modeling them, then executing them and
collecting performance data that enables you to analyze the processes for
improvement. Because you are working with actual performance data that
has been collected during run time, you are no longer estimating or guessing.
What you are really accomplishing is that you are continuously improving your
processes over time. This means that a process is never done and finished.
There are always improvements that you can apply to the process because of
changing competitive pressures, new regulatory requirements, or other
improvements that you find.
With this in mind, it is important that the BPM suite supports ease of
changes to a process. It should also have built-in capability to capture
process performance as the process executes, reporting for viewing
operational real-time reports and historical reports so that you can look at
historical trends.
The tool should also support analysis of historical data to enable you to find
bottlenecks and other historical trends. If you do not have these built-in
capabilities, you have to manually capture and analyze all of this data.
1.1.2 When
Now that we know a little more about BPM and how it can be used with a BPM
suite, the next question is, when is a BPM suite a good fit for a project? This is a
very important question, because in our experience, this can have a big effect on
if your projects are successful or not. We have seen projects fail where a BPM
suite has been used more as an application development tool in isolation without
the iterative approach of BPM.
The issue here is typically that business users are only involved up front when
the initial requirements are captured, and do not see anything until the project
goes live much later. However, requirements change frequently these days. This
does not mean that if you use a BPM suite as a pure application development
tool your project is doomed to fail, but in our experience the risk is higher.
Now, examine what typical problems you would find in a process that is executed
in a manual and unstructured way compared to what a BPM suite offers.
It is amazing how many business-critical processes today are still managed and
run manually. We would even go as far as to say that the most-used tools for
running processes are email and spreadsheets.
There are many issues when you are running a process manually:
Visibility
Visibility into your processes becomes difficult if not impossible when you
either run your process manually, or the process spans multiple enterprise
systems or departments. One option is to try to manually capture the data
needed, such as processing times and so on.
However, this is typically difficult and error-prone. From an operational
perspective, it becomes challenging for process owners and people working
with the process to get an overview of how they are doing.
For example, from a team managers perspective, it becomes difficult to get
an overview of what the team is working on. Who is working on what, and how
much work do they have? This can have a big effect on client satisfaction.
8 Business Process Management Design Guide: Using IBM Business Process Manager
Process variation
With manual processes, you are relying on the user to know what they should
do and what the next step in the process is. This invariably leads to many
variations in how the process is executed. In turn, variations increase the risk
from a compliance perspective, because you cannot guarantee the flow of the
process. It also means that it is difficult to measure and improve the process,
because you cannot be sure that you are comparing apples to apples.
Missing information
One of the biggest issues with manual processes in our experience is rework,
because this is both time-consuming and costly. Rework in manual processes
is made much worse because users have to manually enter or reenter data
into multiple systems. This many times leads to the wrong data being entered
or even missing all together. The outcome of this is rework.
Hidden or missing work
With manual processes there is always a risk of missing or losing work,
especially if you rely on emails, because these can easily be missed or
deleted. This in turn can lead to work not being completed on time, which in
turn has an effect on client satisfaction.
So, how can a BPM suite help to mitigate these issues? A BPM suite introduces
a layer of abstraction between the user and the back-end systems. The process
interacts with the back-end system, typically with an enterprise service bus
(ESB), and interacts with the users through built-in UIs. Therefore, the user only
has one interface to work with, and it presents the information that the user
needs to complete the task.
The process is modeled and executed within the BPM tool. The benefit here is
that the same process is always executed, minimizing risk. Put in another way,
the processes becomes predictable, repetitive, and easy to measure. The
process also handles the routing of work to make sure that the correct person
always receives the correct task. A BPM suite also gives you end-to-end visibility
across the process.
Business agility
The business world we live in today is changing faster than ever. To stay
competitive, companies have to change quickly or see themselves be overtaken
by competitors that can adapt to new business needs more swiftly. Because of
this, businesses are becoming more and more demanding as to how often and
how quickly they need changes.
This puts extra pressure on information technology (IT) organizations that are
typically already overworked and have limited budgets. It is in this environment
where BPM can help, with its iterative approach of delivering small incremental
releases and value often. IT can also offload some of the work, such as process
discovery, to business. This means they can concentrate on the tasks that add
more value.
10 Business Process Management Design Guide: Using IBM Business Process Manager
Changes have to be done more rapidly to meet the ever-changing competitive
landscape. The effect of this has been that IT struggles to keep up with modified
business requirements.
Not only can you develop new processes and change existing processes quickly.
BPM also helps to align project goals with the business needs, because business
people are involved at all stages during the development cycle.
Figure 1-3 shows the typical phases in the standard playback methodology.
For more information about how to best apply the playback methodology, see the
IBM Redbooks publication Scaling BPM Adoption: From Project to Program with
IBM Business Process Manager, SG24-7973.
Visibility
One reason many companies start looking at BPM is the need for end-to-end
process visibility. It is key to have reliable performance metrics if you want to start
improving your processes with a degree of certainty. Some clients have
processes that span multiple vertical systems. Each of the systems might have
workflow and reporting built in, which provides visibility into the system. However,
they struggle to get full end-to-end visibility.
This becomes even harder when the process also spans multiple departments. A
simple example to illustrate this would be the onboarding process for a new
employee. One might think that this process mainly involves human resources
(HR). However, it typically touches many other departments and systems, and
this makes visibility across the process difficult without a BPM suite.
From an operational point of view, BPM enables users to review the performance
of processes in real time and take actions. This could be a user reviewing all of
the tasks that she is working on to understand what is the most important item of
work. This can be classified by priority assigned to work, or from a time
perspective, such as what is due today, tomorrow, and so on.
Compliance
Organizations today must comply with an ever-growing set of government
regulations. Not only is the number of regulations growing, but the current set of
regulations is often not that clearly defined. They also change often. Regulations
are getting increasingly complex, as special cases and exceptions surface.
12 Business Process Management Design Guide: Using IBM Business Process Manager
A BPM tool can help organizations to comply with regulations, because it
enables easy and quick changes. It also helps with auditability and traceability of
processes. From a broader perspective, it helps organizations to keep costs
down when you are required to adhere to many different regulations, because a
BPM solution is a platform where you can implement any process across the
organization to comply with regulations.
In fact, we have seen an increase over the last couple of years in organizations
offering business process outsourcing. These organizations offer compliance
processes for many different regulations for example FATCA, The
Sarbanes-Oxley Act (SOX), Know Your Customer (KYC), Payment Protection
Insurance (PPI) Remediation, and so on. The case is very compelling for both
client organizations and service providers.
Client organizations can focus on their core business, and service providers can
provide compliance as a service and do repeat business, because regulations
are the same for all clients. They can come with a unique value proposition
where they provide high-quality service. Again, service providers need to come
to the market with a uniform platform and practice, and visibility and agility are
strong value points.
The following list includes some of the most important aspects where a BPM
solution helps organizations with regards to compliance with regulations:
Agility
Due to the fact that a BPM suite supports quick and iterative development, it
enables organizations to quickly change their processes and adhere to
ever-changing government regulations.
Visibility
When implementing processes, organizations gain a new level of visibility with
regards to how processes are implemented. This makes it much easier for
organizations and auditors to make sure that they adhere to regulations. Chief
Compliance Officers also need such visibility, because they are getting more
constraints on their agenda. Remember that, with a BPM solution, what you
are modeling is also what you are executing.
Workforce efficiency
One of the issues with manual processing is that you very much rely on the
individual employee and their knowledge of the process. Every employee makes
slightly different decisions, which means the process isnt exactly repetitive and
predictable, which leads to increased risk.
This also means that it becomes more difficult to improve the efficiency of a
process. One aspect of this is the need to minimize the amount of time in the
process being wasted trying to figure out who should have the work item after
you complete it.
This might not be such a big issue for the heroes in an organization that have
in-depth knowledge and have worked with the process for a long time. This is
often referred to as the hero culture, where a few very knowledgeable people
become the people that do much of the work. These same people help and guide
other employees.
14 Business Process Management Design Guide: Using IBM Business Process Manager
Hero culture often makes it hard for organizations to grow, because they rely on a
few employees with in-depth knowledge of the processes. In fact, a BPM system
can help to encode the knowledge and best practices from these heroes to
enable other users to get up to speed faster and become productive.
The following sections provide information about some of the aspects regarding
workforce efficiency and the benefits of BPM.
Routing
With manual processes, it is the employees responsibility to know who to route
the work to next. For a simple process, such as applying for time off, it is typically
reasonably simple. You complete the form and email it to your manager, who
approves (or declines) and then sends it on to HR. However, if you consider more
complex and business-critical processes, such as a claims request, it becomes
more difficult.
The reason for this is that the routing of a specific work item is many times based
on many different attributes, for example the type of claim, client status, severity,
location, priority, and so on. It also depends on the skill and availability of the
employees handling cases.
This leads to wasted time as the employee looks up instructions or sends it to the
person the he thinks should have it. That person in turn passes it on to somebody
else that should have it. Even worse, the person you send the work to might be
out of the office and so cannot do the work. The consequence of this is that the
work sits in an inbox for days or weeks without being actioned.
A BPM suite enables you to encode the routing rules in the process. Two of the
benefits are that you reduce the risk, because you always get the same result
from the routing rule for the same input. You also speed up the process, because
the task is routed to the correct person immediately.
Another benefit with routing rules that are encoded in a BPM suite is that you can
also start using more complex rules based on the skills and workload of
employees. An example of this could be when a claim comes in to the claims
department, the process first executes a routing rule that takes into account the
complexity of the case and what skill is needed.
It can also look at who of the people that can actually handle the claim has the
least work, and then route it to that person. You could even implement the
concept of follow the sun if you have employees in different time zones. An
example of this is the automatic reassignment of work from a call center in New
York to San Francisco at the end of the day in New York.
For example, in version 1 you might have decided to only implement simpler
routing rules that cover 80% of the cases. You refine the rules in version 2 when
you also have some usage data from version 1. This is why you always need the
capability to manually perform overrides.
Because a BPM suite automatically keeps track of all work, it enables the system
to make business dashboards available with information about what is going on.
This enables a business user, like a team manager, to first get an overview of
what the team is working on before deciding how to assign or reassign work.
Parallel work
This one is probably rather obvious, but it is still worth mentioning, because it has
an effect on the efficiency of the process. You can gain process efficiency by
performing work in parallel. If certain work items or tasks do not rely on each
other, you can speed up the end-to-end process by performing them in parallel.
Data entry
Another issue with manual processes is that many times they span multiple
back-end systems. Different tasks in a process need access to different systems.
In addition, users must interact with multiple back-end systems to get all of the
information that they need to complete one single task.
This involves them having to log on to multiple systems to collect all of the data
manually. They do this using what we refer to as the swivel chair approach,
which is looking at one screen and then swiveling over to the other system to
type the data in.
16 Business Process Management Design Guide: Using IBM Business Process Manager
A BPM solution solves these issues by presenting one consistent interface that
guides the user through the immediate task. This removes the need for the user
to interact directly with multiple back-end systems, because this is handled by the
BPM system.
The window in the BPM system is also designed with the specific task in mind,
and removes any unnecessary data that clutters the window and can confuse the
user. This reduces the chance for errors in the process, which in turn leads to
less rework and in the end quicker completion of processes.
Decisions
Routing rules are not the only decisions being made in a process. Frequently,
you also have process rules that affect the path that the process takes. An
example of this could be where a claim needs to have extra approval if the
compensation in the claim exceeds a certain value. The benefit here is very
similar to the routing rules. It enables you to encode the rules to ensure the same
outcome every time they are executed with the same input.
Knowledge sharing
In the last couple of years we have seen an increase in the use of social
capabilities within BPM. By socially enabling your processes with capabilities,
such as message feeds, screen sharing, and so on, you enable your more
experienced employees, the heroes, to collaborate and share their knowledge
with other users. The benefit is that new users can complete the work faster and
with less error.
An example could be an employee that is new and does not exactly know what to
do, or it could be that she just wants to ask for help from an experienced user to
make sure that she makes the correct decision. Without a socially enabled BPM
system, they can either sit and try to read online instructions, or use the phone to
call a more experienced user if they know who that is. In both cases, they would
waste time. Also, any communication outside of a tool would not be logged.
Process governance
As we have mentioned before, one of the values of BPM is that you can increase
the quality of your processes by modeling them and then executing them in one
single system. A BPM system can also help to drive commonality in processes
across the enterprise. An example of this could be an approval process that is
the same for many higher-level processes.
With a BPM suite, you would implement the approval process once and reuse it
many times. This speeds up the development of the process, and makes sure
that you handle an approval the same way every time.
For many clients this is a big step, because they are used to a waterfall-based
methodology in which you spend a fair amount of time up front gathering and
documenting all of the requirements before handing off to IT for the
implementation. The issue with this approach is that internal and external
business requirements change quickly these days.
We believe that it is much better to deliver incremental value in small steps. This
enables you to adjust quickly to new requirements as they come up.
If you are totally new to BPM, there are also some unique challenges that you
should be aware of. The following sections describe some of the common issues
on a higher level.
For a more detailed description of how to approach BPM and ensure its success,
see the IBM Redbooks publication Scaling BPM Adoption: From Project to
Program with IBM Business Process Manager, SG24-7973.
One approach that we have seen that initially can look promising is to document
all of your most business-critical processes and start implementing all of them at
the same time. The idea behind this is typically that organizations are trying for
the maximum effect. However, we would strongly advise against this approach,
because we have seen it fail many times, for several reasons.
18 Business Process Management Design Guide: Using IBM Business Process Manager
If you are new to BPM, there is a learning curve as you adapt to the new
software, as with any software. Also, if your organization is not used to an agile
and iterative approach to delivery, there is a certain amount of cultural change
that has to take place. Furthermore, it can be difficult to get the full value out of
reusing assets from other projects, and there can be some amount of rewriting
necessary later to cater for reusability.
We advise you to always start small: Do not try to boil the ocean in one attempt.
The first project should always be a process that is smaller in scope but still
delivers business value. It is important that the first project is successful for your
continued rollout of BPM. Success breeds success.
Note also that even if the process that you are planning to implement in a BPM
tool is a large complex process, you can still approach this by breaking it up into
several smaller deliverables or iterations. For example, for the first version you
can still get value by implementing a thin process that just routes the work and
prompts users to complete a task and then report back. From this you would still
get visibility and understand where bottlenecks are, and so on.
Or you might opt to implement a part of the process that is currently causing
issues and go deeper. In iteration 2 you might start plugging in integrations to
automate certain steps.
Remember that it is almost always better to deliver some business value in, for
instance, 90 - 120 days than it is to wait for a more complete solution in 9 - 12
months. Another aspect to remember is that in todays world it is almost certain
that business requirements will have changed anyway in the 9 - 12 months.
The previously mentioned points illustrate why strong executive sponsorship and
effective working relationships between all departments in an organization are
essential. The charter of the BPM CoE is to ensure that these conditions exist.
The CoE has representatives from both business and IT. This is especially
important when it comes to project selection, and when deciding the scope of a
project or iteration.
20 Business Process Management Design Guide: Using IBM Business Process Manager
1.2.3 People
One key aspect of any successful BPM project is the active involvement of
business users and stakeholders throughout the length of the project.
The big risk with this is that very quickly the scope starts to swell and the delivery
date moves. It falls on the project manager to control scope. It is therefore
important that the project manager or the executive sponsor have the power to
make the final decision about what is in or out of scope for the current release.
The first set of points are about getting the people that are involved in the project
access to the correct resources so that they can do their work. The second
section describes things that are typically not thought about at the start of a
project, but invariably affect the success of the project.
The first thing is to make sure that all developers that are involved in the project
have access to all of the correct resources so that they can do their job. This
includes but is not limited to the following resources:
Access to logs on servers for debugging
Access to servers where your BPM server is installed for eventual server
configuration changes, for example, log level
Performance
Believe it or not, a project aspect that sometimes gets overlooked is
performance. This can, for obvious reasons, have a massive effect on the
acceptance of a new process that you deploy. Business users are not going to be
happy if the system is slow. There are many aspects that you must look at during
the project regarding the performance of a BPM system:
Architecture best practices
For a more detailed description about best practices for IBM Business
Process Manager topologies, see the IBM Redbooks publication IBM
Business Process Manager Version 8.0 Production Topologies, SG24-8135.
For more details about architecture best practices, see Chapter 3, Solution
analysis and architecture considerations on page 73.
Development best practices
For a more detailed description about best practices for developing Coaches
with IBM BPM, see the IBM Redbooks publication Leveraging the IBM BPM
Coach Framework in Your Organization, SG24-8210.
For a more detailed description about best practices for developing mobile
user interfaces with IBM BPM, see the IBM Redbooks publication Extending
IBM Business Process Manager to the Mobile Enterprise with IBM Worklight,
SG24-8240.
For more best practices for IBM BPM, see the BPM section on IBM
developerWorks:
http://www.ibm.com/developerworks/bpm/
22 Business Process Management Design Guide: Using IBM Business Process Manager
Performance tuning and configuration
For a more detailed description about best practices for performance with IBM
BPM, see the IBM Redpaper publication IBM Business Process Manager
V8.0 Performance Tuning and Best Practices, REDP-4935 and the IBM
Redbooks publication IBM Business Process Manager V8.5 Performance
Tuning and Best Practices, SG24-8216.
Database configuration, tuning, and best practices
For a more detailed description about best practices for database tuning with
IBM BPM, see the IBM Redpaper publication IBM Business Process Manager
V8.0 Performance Tuning and Best Practices, REDP-4935 and the IBM
Redbooks publication IBM Business Process Manager V8.5 Performance
Tuning and Best Practices, SG24-8216.
Reporting
Many organizations overlook the importance of business reporting when they
begin their process discovery phase in a new BPM project. It is either this, or
reporting is the first thing that gets cut when a project is running out of time.
The lack of business-focused reporting can have a large effect on the success
and acceptance of your project. Therefore, it is important to make reporting a key
aspect of your project. Never implement a BPM project without planning for
business reports.
1.4 Conclusion
In this chapter, we have introduced you to the concept of BPM and the benefits of
a BPM suite. The success of a BPM project is not only affected by technical
decisions that the team makes. Therefore, we have highlighted some of the more
business-focused decisions that you as a team must make, because invariably
they affect the outcome of your project. These decisions have an even bigger
effect if you as an organization have started on a wider enterprise BPM journey.
In the following chapters, we go into more details about the more technical
design decisions that you might face.
Many times, we are asked, What do we do next? Although the answer can vary
depending on the current state of maturity, there are important concepts,
initiatives, and considerations that need to be taken into account regardless of
how much progress you have made to date. Sometimes, the next best action in
your BPM journey implies that there is an order to those steps.
Completing the second step first, or ignoring a step, might make your project
falter or fail, because project risks elevate. Because we do not want you to do
either, it is important for you to know what the next step is, and when the correct
time to implement it is.
Next, we address some common situations to see what the next logical step
might be:
You are trying to identify which part of your organization can benefit most from
BPM.
Next step: Define a heatmap using an IBM Component Business Model, as
explained in 2.7, IBM component business modeling on page 52.
You are considering your first BPM project, but do not know what your
processes really are.
Next step: Conduct a process inventory, as explained in 2.8, Process
inventory on page 56.
You know that you have several processes in your business area, but do not
know which one you should start with. You would like to extract commonality
and reuse subprocesses. You are wondering if there is a way to consolidate
and reuse processes. What about the variations in your processes? How do
you handle them?
Next step: Conduct a Process Inventory, Variation Analysis, and Roadmap
(PIVAR), as explained in 2.9, Process Inventory, Variation Analysis, and
Roadmap on page 57.
26 Business Process Management Design Guide: Using IBM Business Process Manager
You are working on a project and want to get an idea of what it would take to
implement the processes for the project.
Next step: Start blueprinting, as explained in 2.10, Blueprint or Macro
Design on page 62.
You are ready to implement your first IBM BPM application.
Next step: Start your project, as explained in 2.11, Project on page 64.
You have already implemented your first IBM BPM application successfully,
and you are thinking of taking the next big step. You have many processes,
often in different domains.
Next step: Start a BPM program, as explained in 2.12, Program on page 65.
You have many processes that you want to make use of commonality and
implement them in parallel, or you want to deliver large complex processes
more cost-efficiently.
Next step: Set up an IBM BPM Factory, as explained in 2.13, Process
Factory on page 67.
You are using an existing platform for BPM, and want to make the most of the
modern capabilities and features provided by IBM BPM.
Next step: Plan for migration, as explained in 2.14, Migration on page 69.
There are three areas, all based on a foundation of governance and enablement:
Method and approach as a progression
Assets
Skills and capabilities
A business case for automation of one or more business processes provides the
motivating factor. We would like to be able to break out of tightly constrained,
siloed applications, and start building applications from loosely coupled
process steps. Loosely coupled steps enable you to rework the process without
having to completely rewrite the application.
28 Business Process Management Design Guide: Using IBM Business Process Manager
We want to somewhat mirror the way work is done in the business, but with more
automation and efficiency. To accomplish this, we complete the following stages:
1. The first step in the journey typically starts with a discovery workshop of a few
days that explores the details of single process.
2. Later, we move on to a quick win project, which delivers tangible business
value in a short time frame.
3. As we gain more confidence, we map out the project using macro design or
blueprinting, identifying the processes to automate. You also identify the
integrations that need to take place, and the information architecture that
underlies the integrations.
4. If a larger number of processes is involved, we engage in PIVAR so that
we can capitalize on commonality and create a roadmap for automating
multiple processes.
5. With continued success, we can elevate the effort to that of a program level of
sophistication, and involve a Factory model for BPM development that scales
to very large programs involving multiple projects.
Course corrections are then made possible by assessing deviations from the
roadmap that you have created. The roadmap consists of a set of initiatives,
projects that are implemented to get you to your wanted future state in each of
the dimensions defined by the maturity model that you use.
For example, the following dimensions describe the BPM maturity model:
Knowledge worker processes (less predictable, ad hoc, and case-centric)
Automated business processes (more predictable, straight through
processing (STP), and deterministic)
Rules and decisions
Analytics and key performance indicators (KPIs)
Services and integrations
API management
Data or Information Architecture (as it relates to the BPM initiative)
Infrastructure
A tactical project plan is created for the shorter term, and a longer-term plan is
crafted with schedules, initiatives, and objectives to be attained. Resources are
trained and allocated to meet these objectives and timelines.
30 Business Process Management Design Guide: Using IBM Business Process Manager
2.3.3 Agile methods and processes: Driving skills, predictability,
and consistency within the organization
Paramount to large-scale software development across an organization is
consistency and prescriptiveness. This involves large groups of distributed staff
working from the same templates so that activities converge and outputs are
relevant across the organization. Prescriptiveness is important to help guide
technical and business resources to engage in the correct activities to produce
the wanted artifacts and deliverables.
IBM provides a Smarter Process Method for use on BPM and Smarter Process
projects in general, depicted in the following section. It is advised that in the early
stages of the project or program, a Method Adoption Workshop of 1 - 2 days is
convened to decide which aspects of the method will be used for this project
type. Determine which roles, artifacts, and activities are chosen to be delivered
and executed for this project type.
We suggest defining a few project types as the baseline. Map other projects in
terms of size, complexity, and domain (for example, private sector or public
sector, each with their own specific needs) to these base types. The outcome is a
work breakdown structure that can serve as a guide for future projects.
Remember that agile methods are appropriate for smaller projects. As project
size and complexity increase, a tailoring of the agile method needs to be
conducted. For example, it is tempting to assume that, after a quick win pilot or
an initial working prototype, we can continue onward into the full-fledged project
using the same approach.
Often we need to pause after the initial pilot or prototype and look holistically at
the macro level of the project:
The integrations
The architecture as a whole
Database considerations
Infrastructure issues
Configurations for the various development, staging, testing, and production
environments
The key point is that you ensure that it is not an ad hoc architecture that gets built
every time a new project comes along. A basis is established as a standard in
effect, which is adhered to by using governance and management.
Governance defines the policies, and the management function enforces those
policies in practice.
32 Business Process Management Design Guide: Using IBM Business Process Manager
2.4 Business process and Smarter Process Maturity
Model: A roadmap
Most organizations are on a journey of adopting BPM. If you want to increase
your capabilities and BPM area, it is important to understand the current state of
the organization or the section of business that is attempting to use IBM BPM.
You should also define the capabilities wanted to be achieved in a future state.
Figure 2-2 depicts the anatomy of a Smarter Process. The concept of a Smarter
Process is one that combines business rules and decisions within the process,
and integrates with existing and back-end applications and systems of record.
In addition, a Smarter Process is one that can connect and integrate with case
management capabilities, and with structured and unstructured content that
provides context to the knowledge worker who is handling a case. Often, data
and analytics are gathered or monitored as part of metrics and KPIs within the
context of a business process.
34 Business Process Management Design Guide: Using IBM Business Process Manager
Next, we describe the key capabilities that need to be maturing for typical IBM
BPM projects. This approach provides a planning framework to assess where
you are, and where you want to take the next step and enhance existing
organizational capabilities in IBM BPM projects.
The maturity model can also be seen as one of adoption, in which certain
capabilities start to appear, or should be expected to appear at a certain point in
the growth and evolution of BPM within your organization.
In Figure 2-3 on page 34 we show seven dimensions in the rows, starting from
manual processes, to automated business processes, to the rules and decisions
needed to run those processes. It also shows the analytics and KPIs that are
used to define, measure, and ultimately create a feedback loop for improvement
and optimization of the business process.
The next dimension is the all-important SOA, the set of services that will be
started when an activity is activated during a business process. Services grow
into the Representational State Transfer (RESTful) application programming
interface (APIs) that can be made available inside or outside the enterprise.
These APIs ultimately rely on data and information in the systems of record.
The maturity of BPM describes more of a journey within BPM. Although there are
many entry points and possible paths to take within BPM, the maturity model
provides a reference point around which you can plan your journey for BPM. This
model defines the underlying dependencies and possibilities that need to be
considered to arrive at a higher level of maturity or capability in the adoption and
capitalization process of using BPM.
This often manifests in the area of service integrations that denote the
connectivity to back-end systems, which often supply these services or business
capabilities that help run a business.
Note that the fields in each of the dimensions running horizontally are not an
exhaustive list of the aspects of maturity. Rather, they form categories in which
you can perform the following BPM activities:
Consider more details.
Conduct assessments to determine the as-is state.
Designate and agree upon a wanted target or to-be state.
Based on these source and destination points, plot a set of initiatives that
collectively fulfills the requirements and implements the capabilities required
by arriving at a to-be state.
36 Business Process Management Design Guide: Using IBM Business Process Manager
2.4.4 Automated business processes
Map out the process, its activities and steps, the swimlanes, and branching logic
as we go from one activity to the next. Examine the degree of certainty that you
have in each branch or scenario of the process, and who needs to be involved to
make it flow (who decides). Examine the efficiency and effectiveness of the
process in trying to accomplish its goals. Examine the roles within the
organization that participate in the process.
Business processes consist of activities that often use back-end systems for
information, to process the current step and decide what the next step in the
process is. Examine the degree of maturity of those integrations. Are they
currently hard wired, or are they web services calls?
Examine the flow within the business process, the routing that is required
between activities. Sometimes we might require more than routing logic. We
might need a business analyst (BA) or business subject matter expert (SME) to
model the rules separately and the process can use those rules.
This helps you determine how much of the decision can be put in the business
process itself, and how much of it is probably better served by externalizing it into
a rules engine, such as IBM Operational Decision Manager (ODM).
Mine the rules
Where are the rules and decisions today? Are they in spreadsheets? Inside
the organizational tribal knowledge?
Externalize business rules
Are they externalized or embedded within the process?
Model the rules
Do they have a series of filters that needs to be applied for multiple rules, or
are they less complex rules?
Differentiate rule types
Are the rules that you encounter mostly routing rules? Alternatively, are they
true business rules that decide how the business operates? Do they
contribute to the decision of what action to take next, and what back-end
system to pull data from or submit data to, for processing?
38 Business Process Management Design Guide: Using IBM Business Process Manager
2.4.6 Analytics and KPIs
You can record known performance metrics within the process and run
simulations. At other times, if information about a process flow is outdated or
questionable, you might want to start by simulating the existing process in a
swivel chair model:
Current metrics and KPIs
What, if any, measurements do we currently have in place that can be used as
a benchmark? Do we need to make an educated guess based on current
trends and feedback, and run the process first to gather this information?
Measuring the process
What aspects of the process do we want to measure? How can we help the
kanban, kaizen, Six Sigma, lean, or lean Six Sigma efforts through automated
measurements and simulation of the process?
Efficiency
What aspects of the process do we want to constrain and limit in terms of
acceptable execution time of each step, or of the entire process?
This dimension assesses the degree of preparedness or, if in place, the degree
of evolution and growth of the API management effort within the organization to
support key industry trends, such as mobile, social, and analytics:
Mobile strategy
Is there a need for RESTful web services? How are you planning to deliver
mobile solutions, if any?
Factor competitors in technology adoption
Is there a need for competitive advantage through making APIs available, or
using existing APIs, to compose applications that support a cloud-based or
SaaS-based model?
Management of new delivery models
How are we planning to manage the SaaS aspect of the portfolio?
40 Business Process Management Design Guide: Using IBM Business Process Manager
2.4.9 Data, content, and information architecture
A significant portion of a process is predicated on the data on which it relies, both
structured and unstructured. The necessary data is often gathered through
analytics, and stored in systems of record that must be accessed using services:
Data and access
Is the data structured or unstructured? What parts of the process need
access to this content?
Status of standardized data models for information exchange
Is a canonical data model in place? Is a canonical message model in place?
Level of master data management (MDM) adoption
Is an MDM effort in place to consolidate systems of record?
Information lifecycle governance
What is the lifecycle of data and information in connection with the domain
under study, and as it relates to the BPM processes? What data is to be used
within the context of the process?
Data for decisions
Is there data that needs to be used to support rules and decisions? Are they
externalized?
The assessment includes as-is capabilities and wanted to-be capabilities that we
need to put in place for the successful execution of BPM projects:
Environments
What are the specifications for the environments? Install and configure the
development, testing, staging, and production environments.
Monitoring and management
What are the required monitoring and management capabilities?
Support for non-functional requirements
What kind of redundancies and disaster recovery capabilities are required?
Estimation also provides insight into skills, resources, and timelines for budgets
and commitments. One of the initial hurdles to surmount is that of assessing
complexity, which helps estimate the level of effort associated with the project.
There are various levels of estimation, including rough order of magnitude,
detailed estimations, and so on.
Next, We start with the concept of the BPM artifact. The following list includes the
six main IBM BPM artifacts:
Business process definitions (BPDs).
Activities that occur with the business process.
User interfaces or Coaches, as they are called in IBM BPM.
Services. Activities call services that connect to or integrate with back-end
systems of record or applications.
Business rules.
Reports.
So, how many of these will you have on your project? And how long will it take to
build each one?
First, you need to estimate how many of each of these you need to build. Then,
estimate what the level of complexity of each is going to be, within the project
context. Finally, estimate how long each takes to build. Then you can integrate
these three steps into your estimation for additional project activities beyond
development, construction, and testing. Next, we look at this process.
42 Business Process Management Design Guide: Using IBM Business Process Manager
2.5.2 Degrees of complexity
In this section, we describe the aspects of project complexity and provide insight
into how these aspects affect your BPM project estimation and scheduling.
Figure 2-4 depicts several key areas of consideration for your projects. They
consist of a spectrum running from a value on the left to a value or attribution
on the right, which encompasses the range of options or scale associated with
that spectrum.
Statistical analysis of BPM projects shows that there are, in fact, five tiers of
complexity rather than the simplistic three, as shown in Figure 2-5.
You can name them whatever you want. However, note that there is a range that
exceeds the intuitive and commonly held belief, a range that goes far beyond
traditional levels of complexity.
As we cover the spectrums of complexity, consider where your project falls within
each of them. This helps create a more realistic estimate and project plan.
The intent of such a quick win is more a proof of concept (POC) than something
that goes straight into production. The other end of the speed of delivery
spectrum is a program with multiple projects, and possibly the means of
industrializing the development process.
44 Business Process Management Design Guide: Using IBM Business Process Manager
Integration using services (SOA)
Many projects start with the assumption that the underlying integrations are
available, and that the services only have to be connected and called. Therefore,
no further design or construction is required. Often, upon closer scrutiny, this
assumption is found to be false: The services are not ready.
At the other end of the spectrum, we find systems whose requirements are
heavily focused on the back office (back end). These systems have relatively few
human interfaces, and a substantial number of integrations and interactions with
existing systems, COTS applications, or systems of record. A consideration of
the nature of where your project falls within this spectrum helps create a more
realistic estimation and project plan.
This historical data is gathered and analyzed across multiple projects, and can
facilitate, and provide a reference point for, estimation and planning efforts within
the context of your BPM projects. We encourage you to do so, often in the
context of the BPM CoE, which consolidates activities around leading practices
for BPM within your organization.
In gathering and analyzing this data, note that the velocity of each new team will
differ based on skill levels, domain experience, amount of past team experience,
and fundamental complexity of the problem domain, as outlined in 2.5.2,
Degrees of complexity on page 43.
The first column in Table 2-1 represents the BPM artifacts. BPDs are business
process definitions, which contain activities. Coaches refer to the UIs.
Integrations refer to web services-based integrations, where database
integrations pertain to integrations with systems of record.
46 Business Process Management Design Guide: Using IBM Business Process Manager
The complexity spectrum indicates the statistical distribution of each of the BPM
artifacts. For example, about 63% of Coaches are low complexity, about 11% are
medium complexity, and 15% are high complexity. Interestingly, about 7% of
Coaches are very high complexity and about 4% are ultrahigh complexity.
Then we engage in one or more quick win pilots that demonstrate the execution
speed of a project, and its technological possibilities, while providing some basic
value to the business.
Processes are grouped and started in parallel based on their business affinity or
technical cohesion. They are implemented together in multiple groups.
2.6.1 Workstreams
There are two main workstreams for us to consider on BPM projects:
Business Process workstream
The major workstream in a BPM project is the Business Process workstream,
which includes the Coaches, the BPDs, and the activities that comprise
the process.
Services and Integration workstream
An IBM BPM application also needs to access systems of record, and
possibly different sorts of established back-end systems or COTS
applications. To provide this access, we need to have integrations. The
Services and Integration workstream uses a set of services within the context
of an underlying SOA to connect to these resources.
48 Business Process Management Design Guide: Using IBM Business Process Manager
Figure 2-7 shows the two main workstreams for a typical (low-to-medium
complexity) BPM project. If we have a high complexity project with higher levels
of complexity of the artifacts, we can add more workstreams to deal with that
complexity. But on 80% of projects, the two workstreams, business process and
services and integration, are more than adequate.
These two workstreams are the ones to start with on smaller, lower complexity
projects, such as those that can be designated as quick wins. As the duration,
complexity, and number of processes to be implemented increases, we can
decompose each of the major two workstreams into a set of subworkstreams.
A blueprint phase or activity is designed to help provide a holistic picture, set the
landscape and pace for the project, and rework the estimates. The results of this
phase increase your probability of being on time and on budget.
50 Business Process Management Design Guide: Using IBM Business Process Manager
We typically work in at least two workstreams, BPM and services and integration.
We can possibly expand them into substreams as the complexity and richness of
the project increases. This might be true, for example, when requirements exist
for more explicit business rules, databases, or infrastructure considerations.
The agile lifecycle starts with the identification of user-stories, for example, as a
<role>, I want to be able to <action>, in order to <goal>. The total sum for the
entire project is called the product backlog. A prioritized selection is allocated for
each iteration or sprint.
During that iteration, we conduct a micro design activity, where the design is
refined for that release. We build and test the user-stories in scope. Then, if a
planned business significant milestone is achieved, as in most iterations, we
conduct a playback. During the playback, business and IT stakeholders get to
review the running program up to this point, provide comments and feedback,
and decide on the priorities for the next iteration.
52 Business Process Management Design Guide: Using IBM Business Process Manager
As shown in Figure 2-10, a CBM is a matrix visualization of an organizations
business components.
The rows represent the level of accountability. They characterize the scope and
intent of activity and decision making. The three levels used in CBM are
directing, controlling, and executing:
Directing is about strategy, overall direction, and policy.
Controlling is about monitoring, managing exceptions, and tactical decision
making.
Executing is about performing the work.
54 Business Process Management Design Guide: Using IBM Business Process Manager
You can use CBM to create a heatmap to highlight which component is
particularly good or bad at something, for example, the following business areas:
Strategic criticality
Industry leadership
Degree of investments
Using CBM, you can answer the following questions (and other similar
questions):
How well are our investments aligned with our strategy?
You might learn that, for example, that a business component gets a high
degree of investment (funding), however, it is only of low strategic criticality. Of
course, many other kinds of analysis can be made with CBM, too.
For our business process improvement initiative, we can use CBM to highlight
which business component has the highest inefficiencies, most potential for
improvement, most value to the corporate strategy, and so on. We can use
this information to select this area of the enterprise to start looking more
closely into business processes.
Every component has several business processes. Some processes can
even go across several business components. Even though this is the case,
the ownership of the process might lie within one particular business
component.
How do you look closer into the business processes of a particular business
component?
Well, you start with a process inventory, or a PIVAR activity, to identify the
processes that exist, and evaluate which ones to improve or automate to
provide the highest value for the business component.
Details include the process owner, a three - five sentence description of the
process, a rough estimate of size and complexity, the risk associated with the
process, and the level of pain experienced in the as-is process.
The following process details are needed for identification and prioritization for
further assessment and discovery:
Process owner
Short description (three - five sentences)
Size and complexity
Risk
Pain
For more information about process inventories and process discovery best
practices, read the following IBM Redbooks and Redpaper publications:
Scaling BPM Adoption: From Project to Program with IBM Business Process
Manager, SG24-7973
Process Discovery Best Practices Using IBM Blueworks Live, REDP-5111
56 Business Process Management Design Guide: Using IBM Business Process Manager
2.9 Process Inventory, Variation Analysis, and Roadmap
PIVAR examines the processes in scope, analyzes their variations, and creates a
prioritized roadmap for process implementation.
Variations in type or data can be the information we store about clients when
we have different types of clients. Platinum, gold, and silver level clients have
some common attributes, but also might have attributes that are unique to each
client type.
When you arrive at a rental car facility, for example, and you are designated as a
gold client versus a silver client, the process flow can differ. You do not have to
go the counter, submit identification, credit card, pick a car, and so on. With a
gold client, a profile is maintained and reused, a certain class of car is specified
as a default and rented. The gold client can go straight to the car, versus the
client service counter, and pick up the car. They might be eligible for upgrades.
The rules pertaining to a gold client might differ from a silver client. They might
get a free weekend extension, or a grace period for returning the car, and so on.
The hot components are business areas or components that are most relevant to
the subject of our attribution. They are either exceeding a cost threshold or, for
example, exceeding a revenue threshold. They might also be below a certain
threshold that is defined by the attribute with which we are assessing that
business component or capability.
58 Business Process Management Design Guide: Using IBM Business Process Manager
These components are tagged as hot components. If you are using alternative
business analysis methods, such as business capability analysis, a similar
technique might be used, now applied to the business capability.
Figure 2-12 on page 60 shows the different tools that are part of PIVAR:
Group As-Is processes.
Categorize the As-Is processes into baskets based on commonalities and
objectives.
Prioritize the processes considering effect, effort, and reuse (for example,
decision points).
Develop variation analysis to define compression opportunities.
Establish a roadmap for To-Be processes implementations.
60 Business Process Management Design Guide: Using IBM Business Process Manager
Variation Analysis
Figure 2-13 depicts the variation analysis of PIVAR. Common components
across the portfolio of business processes are identified. With this, potential
for reuse can be revealed, an opportunity for reuse identified, and the chance
for alignment of operational procedures created.
Figure 2-13 Variation Analysis explores the potential for reuse by separating variations
Roadmap
To create the roadmap, the outcomes of the previous stages, process
inventory, and variation analysis are used to create a sequence of which it is
most beneficial for the company to implement the processes. The sequencing
takes into account what the effect of each process is:
Business value
Pain points
Financial effect
62 Business Process Management Design Guide: Using IBM Business Process Manager
2.10.2 Integrations and services
Integrations with back-end systems and systems of record are often not
uncovered until later in the project. This often leads to rework and project timeline
extensions, because the effort to integrate surpasses initial, often
underestimated expectations. Verify the understanding that the result of
integrations indeed meets the business goals. Look at the overall requirements,
specifically focusing on integration:
1. Discover integration requirements and dig into the existing integration
requirements to acquire better understanding of a state of the existing
systems and services that are going to be integrated with IBM BPM.
2. Determine the nature and complexity of integration services:
Are existing services truly ready to be used for integration with back-end
systems? Do we need to build new services, or are the existing ones
adequate?
Is the service specification that describes the details of the
services available?
Identify skill set requirements and resource availability to support the
integration effort.
3. Explore the architectural implications of integration with backend systems and
with systems of record (databases).
4. Analyze the wanted future state process and to-be solution architecture, and
identify what needs to be in place to ready the integration points for
implementation with IBM BPM and IBM ODM.
5. Identify dependencies between integration points and processes.
6. Identify the dependencies and cadence of iterations between the IBM BPM
and the integration tracks.
7. Identify the business priorities for the integration points and BPDs. This
affects the release schedule.
Many of the benefits associated with successful BPM projects, such as reduced
time to market, realized business value, and shortened test cycles, rely on an
iterative development lifecycle to achieve them. In preparation for the iteration,
we prioritize the remaining user stories in the product backlog (the total features
and user stories that need to be implemented for the project) that have been left
from the previous iteration.
Playbacks give stakeholders the opportunities to provide feedback that drives the
next iterations of process development. To perform the playback, we must agree
that there is enough business-significant content to warrant the meeting.
Also key to the playback is to converge the integration stream with the BPM
stream of work.
IBM BPM enables rapid playbacks of the process definition at any point in the
development lifecycle. In the Process Designer tool, you develop a model for
discussion and visualization, but also an actual model-driven, runtime solution.
At any point in development, you can run the process, its subprocesses, and its
services to validate your design.
For more information about how to set up or run a project and playbacks, read
the IBM Redbooks publication Scaling BPM Adoption: From Project to Program
with IBM Business Process Manager, SG24-7973.
64 Business Process Management Design Guide: Using IBM Business Process Manager
2.12 Program
You have been successful with implementing one or two quick win process
deployments that have a measurable effect on your enterprise value chain. Now
it is important to scale this up into a program, so you can automate more
processes, capitalize on commonality and reuse, and have a more standardized
approach across the line of business or ideally, the enterprise.
IBM BPM is most effective and valuable when deployed at an enterprise level,
integrating all processes with the value chain and extending the reach and effect
of shared processes and process assets. It should be no surprise that the same
principles used to improve a business process can improve a BPM program:
Measurable business effect
Incremental delivery
Transparency and visibility
Control over your business
Measure the value and effect of BPM by proving business value in short iterative
cycles. Market that value early and often by providing visibility into that value for
stakeholders and management. Repeat these procedures and prove that the
value of BPM is not unique to a single process, department, or delivery team.
For more information about how to implement a BPM program, refer to the IBM
Redbooks publication Scaling BPM Adoption: From Project to Program with IBM
Business Process Manager, SG24-7973.
Rolling up a process KPI to the corporate value chain is one way to achieve the
goal of elevating all the way from project to process to enterprise level. To begin
with, you look for common metrics between different processes. Your best
candidates are metrics, such as cost and time, because they are almost always
measured in any process.
This situation assumes that your first business process is running in production
for a few months. You are now starting to work on your next business processes,
and trying to extend the visibility across all processes, using common
performance indicators.
For more information, see the IBM Redbooks publication Scaling BPM Adoption:
From Project to Program with IBM Business Process Manager, SG24-7973.
66 Business Process Management Design Guide: Using IBM Business Process Manager
2.13 Process Factory
You have successfully started your IBM BPM adoption, and you successfully
delivered one or more processes of different complexities. The maturity of BPM
in your company increased, and youre ready to move to the high end of the
adoption journey. Then, you want to consider to make use of the approach of an
IBM BPM Factory.
The IBM BPM Factory, also sometimes called Process Industrialization, can
include projects of any complexity. In this approach, you externalize parts of your
projects into a factory, which for example can be a remote development team
with a focus on particular capabilities:
Implementation of human-centric processes
Implementation of system-centric processes
Implementation of business services
Implementation of business rules
Because you have these different development streams, you have to make sure
to account for them in your project planning activities. It is of course important to
keep the interdependencies of the development streams in mind.
Here the standardization of the six pillars of BPM outlined in 2.3, The six pillars
of success for BPM on page 29 become even more important. Using a standard
method such as the Smarter Process Method becomes a critical success factor.
The intent of the development streams is that you can use lower-cost resources
in a distributed fashion, and define concise delivery packages to deliver
functionality fast and cost-efficient.
Because we want to stay as agile as possible, and because when were agile
collaboration is key, we would have our process analyst team on site with the
process owner and subject matter experts to define the process and its
requirements (user stories).
68 Business Process Management Design Guide: Using IBM Business Process Manager
While this happens, the solution architect defines implementation guidelines and
patterns, and helps break down the requirements in concise development
packages that can be handed off to the off-shore development team. The
offshore development team realize the requirements that will be played back to
the business by the end of the iteration.
Typically, you keep key resources, such as the analyst and architect (at least at
the beginning), closer to the business to get feedback and gain understanding.
However, as your project progresses and communication models and refinement
cycles got established, an even larger portion of the onsite staff can be shifted
toward the factory location.
2.14 Migration
Concepts of BPM or workflow management have been around for quite some
time. Therefore, many organizations have a certain degree of technology support
or automation for their processes implemented. But as the business changes,
technology changes as well. So it often happens that the current process
technology becomes outdated and must be modernized.
To get your outdated processes onto the new platform, you have to perform a
migration. The following are typical types of migrations:
Version-to-version migration
Migrating from any old IBM BPM version (Teamworks, Lombardi,
WebSphere Lombardi Edition) to IBM BPM.
For more information, see the IBM Redbooks publications IBM Business
Process Manager V8.5 Performance Tuning and Best Practices, SG24-8216
and Business Process Management Deployment Guide Using IBM Business
Process Manager V8.5, SG24-8175.
Instance migration
Migrating a running instance from an older snapshot to a new snapshot
version.
Platform migration
Migrating from a non-IBM BPM platform to IBM Business Process Manager.
Platform migration is often a migration from either third-party products or
internally developed process applications, to IBM BPM.
What to consider for migration: Migrate the who, what, and why, not
necessarily the how.
70 Business Process Management Design Guide: Using IBM Business Process Manager
Use the opportunity to perform process optimization.
BPM is a discipline that is based on continuous improvement. Chances
are that you havent had an improvement cycle in a while. In this case, use
this opportunity to revisit the process requirements, pain points, KPIs, and
service level agreements (SLAs) with your business. In this case, you can
approach the migration almost like a reimplementation.
That means, you have a discovery phase that leads into
(re)implementation or migration. During the migration, you use as much as
you can from the old application (for example integration services), but
also implement new or changed requirements. Do this by using the
information of the old application in combination with the new findings of
the discovery phase.
2.16 Conclusion
In this chapter, we have described some of the key concepts and approaches to
making BPM a success. We described the pillars of success that are important
workstreams that we need to start working on. Among them is a roadmap for
BPM supported and informed by a BPM maturity assessment.
72 Business Process Management Design Guide: Using IBM Business Process Manager
3
We outline the most common challenges that BPM solution architects can come
across during the initial stage of the project.
We share good practices and considerations that aim to help the IBM Business
Process Manager (IBM BPM) practitioners create scalable designs for robust
BPM solutions, using the IBM BPM product suite.
The previously mentioned information helps you formulate the goal of the
business process initiative, and with this, the goals of your architecture. (More
information about process analysis can be found in the IBM Redpaper
publication Process Discovery Best Practices Using IBM Blueworks Live,
REDP-5111.
Another result of your process analysis phase is the user stories, which are your
functional requirements. Every element of the process (the process itself,
process steps, decisions, and so on) has a least one, but mostly many user
stories. The importance of user stories is that they can be prioritized and
estimated, which is key for successful solving and planning of a project.
More information about user stories can be found in Scaling BPM Adoption:
From Project to Program with IBM Business Process Manager, SG24-7973.
Most often, process goals concern saving time, and saving cost by being more
efficient or having more automation. This is exactly where your architecture
comes into play.
By analyzing your As-Is process, you can identify process activities that can be
executed more efficiently:
You can increase the level of automation by integrating with the correct
system, to gather information, store information, externalize decisions, and
so on.
You are able to learn whether additional services must be created, or whether
the current portfolio is sufficient.
You can improve the level of data aggregation or service orchestration, and
make sure that its being done at the correct level (service versus process).
As you can see from these points, were starting to touch the broader context of
our application (app). Therefore, as you are creating the solution architecture,
you need to make sure that you position it on the correct level.
74 Business Process Management Design Guide: Using IBM Business Process Manager
Therefore, learn which other applications are calling IBM BPM (inbound
integrations), which ones are getting called (outbound integrations), and which
technology is used to do both calls. The commonly known architecture artifact
called System Context Diagram is your best option to create such an overview.
As in most IBM BPM projects, integrations are on the critical path, so you want to
get clarity about them early on.
Also, dont forget that your application itself might require a data store, rule
services, or other externalized components to be created. In sum, you have to
consider components that are part of your application, and consider components
that interface with your application. Based on this information, you can create the
architecture overview. Mostly it is visualized in a layered architecture design, but
the service provider - service consumer pattern is also widespread.
As you look closer into the process model, in addition to integration services from
all components, you can start to design your business object model (BOM).
Details about how to do this using either a Top Down or Bottom Up approach can
be found in 3.3.3, IBM BPM business object model design considerations on
page 92.
In sum, because you are in the phase of creating a high-level solution design and
architecture, the following five artifacts have been demonstrated to be important:
Process model
User stories
System context
Architecture overview
Business object model
All of these artifacts can help to define the scope of your application, and to
create reliable estimates and plans to further the progress of your IBM BPM
implementation project.
The following sections and chapters help you to make the correct architectural
and design decision, so that the goals of the solution can be achieved.
Being high-level in nature, each of the following items addresses one aspect of
an overall architecture. Each item can potentially have a significant effect on the
solution if overlooked or not properly addressed.
They are primarily for compatibility with IBM BPM before version 8.0. For
processes created with IBM BPM version 8.5 5.0 and later, Coaches are advised.
For more information about Coaches, see the following IBM Knowledge Center:
http://www.ibm.com/support/knowledgecenter/api/content/nl/en/ssfpjs_8.5
.5/com.ibm.wbpm.wle.editor.doc/topics/ccoaches.html
For more information about Coach Views, see the following IBM Knowledge
Center:
http://www.ibm.com/support/knowledgecenter/api/content/nl/en/SSFPJS_8.5
.5/com.ibm.wbpm.wle.editor.doc/topics/cviews.html
Another suggested resource to learn more about Coaches and Coach Views is
the IBM Redbooks publication Leveraging the IBM BPM Coach Framework in
Your Organization, SG24-8210.
76 Business Process Management Design Guide: Using IBM Business Process Manager
In IBM BPM, human services provide the logic and user interface through
which users can view and interact with business processes, cases, data, or
process instances.
Figure 3-1 provides a high-level overview of the design and runtime Coach
View structure.
Some organizations consider not using IBM BPM Coach technology for building
UIs for their process applications:
Organizations with corporate information technology (IT) policies that limit the
number of UI technologies permitted to be used
Organizations that have invested in a single UI framework with employees
skilled in the platforms specific technology
IBM BPM provides a set of application programming interfaces (API) that are
implemented based on Representational State Transfer (REST) services. A set
of REST resources is available to access IBM BPM artifacts, including business
processes and tasks.
Because there are many resources available for development using REST API at
the following IBM Knowledge Center, there is no need to cover that content here:
http://www.ibm.com/support/knowledgecenter/SSFPJS_8.5.5/com.ibm.wbpm.bp
c.doc/topics/cdev_restapis.html?lang=en
You can create external implementations for activities that are handled by
applications outside of IBM BPM. For example, you can model an activity that is
run by a custom Eclipse rich client platform (RCP) or Microsoft .NET application.
78 Business Process Management Design Guide: Using IBM Business Process Manager
Figure 3-2 shows how external human tasks can be implemented in the IBM
Process Designer in IBM BPM 8.5.5. In a similar fashion, the external system
tasks can be implemented by using the System Task artifact available from the
same Implementation combination box.
For more information about using external implementations, see the following
IBM Knowledge Center:
http://www.ibm.com/support/knowledgecenter/SSFPJS_8.5.5/com.ibm.wbpm.wl
e.editor.doc/topics/using_external_activities.html?cp=SSFPJS_8.5.5&lang
=en
80 Business Process Management Design Guide: Using IBM Business Process Manager
As an additional design option for the second approach, the IBM BPM
Coaches can be built in such a manner that they can be executed both within
and outside of the process context. This essentially turns this design into a
hybrid approach, where the same Coaches are executed in a regular and a
headless fashion in the same process application.
For example, a client wants to be able to start tasks from the portal and, at the
same time, to have a UI that provides visibility into business data, including
process-related business objects. The client wants to be able to start these
tasks at any time, without owning any tasks, and with no respect to the
statuses of the currently running processes.
Here we focus on use of the IBM BPM Advanced Integration Services (AIS)
artifact that IBM BPM offers for advanced integrations.
A Top Down approach is driven by the process developer, and reflects on the
nature of process development, using IBM Process Designer. This approach
places the focus on the process definition and UI design. More specifically, the
design of both business object types and service interfaces starts in IBM Process
Designer, addressing the requirements for the business processes and Coaches.
More information about BOM design considerations can be found in BOM Top
Down approach on page 93.
Benefits
Next, we highlight some of the benefits of the Top Down approach:
Support for data types and interfaces that originate in IBM Process Designer.
Keeping the mapping effort to a minimum on the IBM Process Designer side.
Keeping most of the mapping effort on the IBM Integration Designer side,
which is equipped with more tooling options that are better suited for mapping
heterogeneous data types.
Drawbacks
In most cases, service interfaces built in IBM Process Designer turn out to be
different from the interfaces used in the integration layer on the IBM Integration
Designer side. These services generally serve the purpose of the facade pattern,
primarily supporting needs of the processes and UI. As a result, additional work
is required to produce services definitions that exist on the IBM Integration
Designer side and interact with the facade services.
This might not be a bad thing because, after all, such differentiation supports
loose coupling between the process application and data layer tiers.
Considerations
The key idea behind the Top Down approach is to keep the process layer focused
on the processes and Coaches design. Business objects and system and
integration services created on the IBM Process Designer side should have the
sole purpose of supporting corresponding type and service definitions, which
reflect business requirements set for the organizations processes and UI.
82 Business Process Management Design Guide: Using IBM Business Process Manager
Bottom Up process design
The Bottom Up approach is defined for the scenario where the integration
developer creates the service interface and the service implementation, and then
makes them available to the process developer in an IBM BPM toolkit.
Benefits
The Bottom Up approach can be considered for practical use in a scenario when
the organizations canonical data model closely resembles data types and
services that exist in the process layer on the IBM Process Designer side. The
main goal here is to reduce the effort on the IBM Integration Designer side while
keeping the mapping effort, which takes place on the IBM Process Designer side,
to a minimum.
Drawbacks
One of the major downsides of this approach is shifting the data mapping effort to
the IBM Process Designer side. Business objects created on the IBM Integration
Designer side need to be mapped to their corresponding counterparts on the
IBM Process Designer side.
Because this mapping is implemented in the Server Script assets in IBM Process
Designer, it is quite a challenging exercise for more complex type definitions. This
is also true for troubleshooting and maintenance efforts down the road, when the
project progresses, and changes to the originally built interfaces are introduced.
Other considerations
You should make a final design decision based on your projects specific
requirements and circumstances, using the leading practices and considerations
mentioned previously. We advise you to apply the facade pattern when using the
IBM BPM AIS artifact.
For more information about the facade pattern implementation, usage, and
strategies, see 5.5.3, Design patterns and performance considerations on
page 190.
Several leading practices regarding use of the AIS artifact have been developed
over the last several years. These practices are a result of real life business
process engagements with complex system integration implementations.
Lessons learned have been collected and thoroughly analyzed for every
engagements specific scenario.
For example, using web services clients can provide a lesser degree of coupling
between the IBM Process Designer and IBM Integration Designer environment
due to its different deployment model. Based on your projects requirements, this
can be a fair trade-off option to consider if the requirements enable such flexibility
in functionality.
For more information about the IBM BPM Advanced Integration service usage
see the IBM developerWorks site:
http://www.ibm.com/developerworks/websphere/bpmjournal/1106_taylor/1106
_taylor.html
84 Business Process Management Design Guide: Using IBM Business Process Manager
3.2.3 IBM BPM Standard or IBM BPM Advanced
This topic highlights the design considerations that typically influence the choice
between IBM BPM Standard and IBM BPM Advanced product configurations.
IBM BPM Standard can be considered when the following requirements exist:
Need for high business involvement in modeling business processes, and
rapid deployment of business processes.
Need to implement human-centric business processes in a highly
collaborative business environment.
Ability to use business rules to drive decisions in business processes.
Ability to proactively monitor business process performance and
team performance.
Need for basic system integration support.
IBM BPM Advanced can be considered when the following requirements exist in
addition to all or some of those that apply to IBM BPM Standard:
Need for basic case management capabilities in business processes.
Need for straight through processing (STP) of business processes with no
human interaction, and the ability to maintain process state between steps.
Need for advanced integration support with external systems.
IBM BPM Advanced should be considered when the following requirements exist:
STP of business processes with no human interaction involving business
results and business outcomes. Such processes typically require maintaining
process state.
Business processes providing services externally, for example, making a web
API available.
IBM Integration Bus should be considered when the following requirements exist:
Complex data mapping for messages.
Need for high-throughput messaging.
Support for a wide range of messaging and integration patterns. IBM
Integration Bus offers a patterns framework with the ability to use both built-in
and user-defined patterns.
Need to implement common industry standard message formats, such as
SWIFT, Electronic Data Interchange For Administration, Commerce and
Transport (EDIFACT), Accredited Standards Committee X12 (X12), Financial
Information eXchange (FIX) Protocol, Health Level Seven (HL7), and
point-of-sale (POS) transaction log (TLOG).
Need for a service exposure gateway.
Connectivity between systems using a special type of protocol, such as
Common Object Request Broker Architecture (CORBA) or IBM WebSphere
MQ Telemetry Transport (MQTT).
Default message throttling capability.
Business processes using services offered by external systems.
For more information about features available in IBM Integration Bus, see the
IBM Integration Bus Knowledge Center:
http://www.ibm.com/support/knowledgecenter/SSMKHH_9.0.0/com.ibm.etools.
mft.doc/bm33084_.htm
86 Business Process Management Design Guide: Using IBM Business Process Manager
3.2.5 IBM BPM rules or IBM Operational Decision Manager
In any BPM project, you implement rules to handle decisions, such as
application-specific decisions, task routing, process routing, and so on. In most
cases, the built-in rules capability in IBM BPM is sufficient for what you need.
However, there are cases when you can benefit from using an external rules
engine, such as IBM Operational Decision Manager, to manage some of your
rules. Note that you seldom externalize all of the decisions in a process. Simpler
process rules tend to remain in IBM BPM. An example of this could be a simple
process routing rule, such as if the value of the order is more than $50,000 you
need extra approval.
It is important that you review and decide if you are going to use an external rules
engine from the beginning of your project, because any change later can be both
time-consuming and costly.
The answers to these questions have an effect on whether you should use an
external rules engine, such as IBM Operational Decision Manager.
88 Business Process Management Design Guide: Using IBM Business Process Manager
3.3.1 Introducing an external SOR into the IBM BPM process
application solution
Before we get started, we define a few terms that we use as the fundamental
terminology in our description of the IBM BPM solution:
A system of record is a data store, hosting information in a structured fashion,
enabling retrieval and updates as needed for its purpose. In most cases, an
SOR is a database-based repository.
The term process data refers to the body of information pertaining to the basic
lifecycle functions of any business process, including but not limited to the
following examples:
Task start time
Wait time
KPIs
SLAs
The process data SOR is intrinsic to the process system. In general, this data
is of most use to improving the business process when it is viewed in
aggregate, rather than the specific details of one instance of the process. The
values of the process data differ for each solution, although the types of data
collected for a process remain the same across all process applications.
The term business data refers to any information related to the specific and
detailed attributes of the particular business process. These attributes are
generic building-blocks of any process system, such as tasks, business
process model, KPIs, SLAs, escalations, and so on, that are used to
accomplish the process.
For example, in a Submit Time Off Request process, business data includes
attributes, such as Employee ID, Type of Time Off, Number of Time Off Days,
and so on. The business data SOR should be distinct and disconnected from
the process data SOR, because it needs to support various other consumers
and subscribers to its data. This data is generally needed to determine the
specifics of a particular instance of a process.
The execution context includes the state of the human service while it is being
run, including the current state of the variables and the position in the service
flow. Effectively, the execution context, as defined previously, includes among
other things the business data that is being carried through the process. For
the purpose of our example here, we use the execution context and the
business data interchangeably.
Although some processes might use similar business data, it is much more
common that each process has its own set of data collected as part of the
interaction with the process.
90 Business Process Management Design Guide: Using IBM Business Process Manager
For more information about headless processes and Coaches, see
Considerations for headless processes on page 78.
Are there requirements to track and report on inflight process instances with a
significant amount of business-specific attributes?
For example, reporting on complex attributes, such as lists or maps, requires
either adding extra variables or persisting data in an external SOR:
Adding extra variables of simple data types usually involves manipulating
the data to populate those variables for reporting purposes.
More often, such manipulation is not a feasible option. In those cases
persisting data in an external SOR becomes an attractive option.
Separating the business process from its data has been a long-standing topic in
BPM architectures. This approach enables strong decoupling between the
respective lifecycles, which yields the benefit of managing each side
independently without impacting the other side. A model of separate ownership
of the process and business data enables a fairly straightforward mechanism.
If an IBM BPM Advanced configuration is used, there often can be two separate
BOMs maintained in the solution. One BOM supports UI and human-based
processes, and another BOM is implemented in the integration layer in IBM BPM
Advanced. In addition to these two logical object models, clients usually maintain
their own enterprise-level BOM.
92 Business Process Management Design Guide: Using IBM Business Process Manager
There are several reasons for separating and maintaining different BOMs for
process, integration, and data layers:
Each BOM serves its own purpose.
A BOM supporting UI and process execution context can be quite different
from a BOM that supports integration with the clients back-end systems,
because separate business and system requirements attributed to each side.
Usually, a BOM supporting UIs and processes is a subset of a more complete
and complex BOM that is required to interface with the clients external
back-end systems.
Each BOM is intended to support its domain with the most efficiency possible.
To ensure the most responsive UI from a data exchange prospective, a BOM
should only contain data that is necessary to present the content to the users
and support processes execution. Anything else in addition to that affects UI
performance, and places an unnecessary load on the runtime server.
Next, we consider some challenges that result from BOM separation, and
discuss approaches and design options.
We choose to reuse the Top Down and Bottom Up naming convention for the
BOM design description. It emphasizes concept similarities. It also helps draw a
parallel between the Top Down and Bottom Up approaches described earlier in
3.2.2, Top Down versus Bottom Up design considerations on page 81:
Under the Top Down approach, the data is originated in and flows from the
IBM Process Designer to IBM Integration Designer.
Under the Bottom Up approach the data moves in the opposite direction.
One of the major benefits of the BOM Top Down approach is that it mostly
eliminates the complexity associated with the mapping between the IBM Process
Designer-based BOM and the IBM Integration Designer-based BOM.
There are several possible variations on the BOM Top Down approach.
Figure 3-3 depicts an example of the BOM Top Down implementation option.
94 Business Process Management Design Guide: Using IBM Business Process Manager
The following list describes the main drawbacks of the BOM Bottom Up
approach:
Data type mapping is necessary on the IBM Process Designer side. Because
mapping is performed inside the JavaScript code, it can result in development
resource demands. Depending on the nature of the changes, the resource
cost can be significant, and it can affect code maintenance and potential
further extension.
Due to limitations on the IBM Process Designer side, certain type definitions
cannot be successfully propagated from IBM Integration Designer to IBM
Process Designer. The workaround can require using alternative compatible
types, which in turn requires an extra mapping effort to populate data into
these compatible types.
Figure 3-4 outlines Extensible Markup Language (XML) schema limitations in
IBM Process Designer.
The most difficult mapping between the IBM Process Designer-oriented BOM
and canonical BOM is performed on the IBM Integration Designer side. Although
there is still a mapping that has to be done in IBM Process Designer, from IBM
Process Designer-oriented to actual IBM Process Designer model, the level of
effort and complexity can be drastically reduced.
96 Business Process Management Design Guide: Using IBM Business Process Manager
Do the other systems consumers require the most recent IBM BPM content to
be available at all times, or at some periodicity?
Does the clients SOR require transactionality while performing data
persistence?
Each of these items has a direct effect on the process applications integration
layer design. In addition, performance implications need to be considered as a
potential side effect of the chosen design and implementation approach.
As a result, implementation of the specific strategy can also vary in effort and
complexity. For this reason, it is important to analyze any related requirements on
the subject of concurrent data access early in the project, because the access
locking implementation has a direct effect on the data access services design.
In general, the same locking strategies are applicable for IBM BPM solutions as
for any other enterprise-level application that requires concurrent data access.
For more information and an overview of locking strategies, see the following IBM
developerWorks article:
http://www.ibm.com/developerworks/websphere/techjournal/0603_ilechko/06
03_ilechko.html
98 Business Process Management Design Guide: Using IBM Business Process Manager
The IBM BPM default caching service results option was introduced in IBM
BPM 8.0 and later. For the setting to enable caching of service results, see
Figure 3-5.
For more information about enabling caching of service results, see the
following IBM Knowledge Center:
http://www.ibm.com/support/knowledgecenter/SSFPJS_8.5.5/com.ibm.wbpm
.wle.editor.doc/topics/team_retrieval_service.html?cp=SSFPJS_8.5.5&l
ang=en
In addition to caching of service results, there are several options that can be
considered for reference data caching in the IBM BPM process application:
IBM DynaCache as a preferred custom option.
For more information about using IBM BPM with IBM DynaCache see the
developerWorks site at:
http://www.ibm.com/developerworks/bpm/tutorials/1210_sharath/
jsCache community toolkit.
Are there existing enterprise services available to access the reference data?
Building services from scratch requires additional time, in terms of
development effort and design time. These required resources need to be
properly estimated and accounted for in the project schedule.
Is the reference data a shared resource in the clients organization?
If the answer is yes, designing enterprise-level services requires more
considerations and potentially more effort, which again needs to be properly
reflected in the project schedule.
This component must start the services in the correct order, and also handle
failure, errors, and any other challenges that come along. Further complexity may
be added by potentially many services on many different platforms in many
different locations. Next, we share some examples of the different types of
integration requirements associated with a business process, and the IBM
products that can be used to address those requirements:
Brokerage and connectivity requirements can typically be implemented using
IBM Integration Bus or IBM BPM Advanced Enterprise Service Bus (ESB).
The following list includes brokerage and connectivity requirement examples:
Message routing
Message transformation
Connectivity across platforms and protocols
Application-specific connectivity using adapters
Content-based message routing
Enterprise application integration requirements can typically be implemented
using IBM BPM Advanced BPEL and IBM BPM Advanced ESB. The following
list includes examples of enterprise application integration requirements:
Event-driven data synchronization
Asynchronous data aggregation
Service exposition requirements can include the following items:
Business processes providing services externally (acting as a service
provider) can be handled using IBM BPM Advanced SCA, BPEL, and IBM
BPM Advanced ESB.
Business processes acting as service requesters can typically use
services implemented using IBM Integration Bus or IBM BPM
Advanced ESB.
Service orchestration and choreography requirements can include the
following items:
STP of business processes with the ability to maintain process state and
provide support for transactionality. This functionality can be implemented
using IBM BPM Advanced BPEL.
STP of stateless services can be implemented using IBM Integration Bus
or IBM BPM Advanced ESB.
100 Business Process Management Design Guide: Using IBM Business Process Manager
After the process integration requirements have been identified, we suggest that
you use the Service Integration and Maturity Model (SIMM), shown in Figure 3-6.
The SIMM was developed by IBM to understand the level of maturity that is
wanted for your integration initiative.
For more information about SIMM, see the following IBM developerWorks article:
http://www.ibm.com/developerworks/library/ws-OSIMM/
Understanding the level of maturity that is wanted from your integration initiative
is important, because it can affect your design considerations:
When designing a service so that it meets maturity level 3, your design
considerations seek to answer the question, how do I satisfy the multiple
known service requesters? In this example, the requesters and providers are
not assumed to be able to talk in a common protocol. Adapters are used to
bridge the protocol or data format gap, and enable communication to the hub.
Adding a new requester requires adding a new adapter.
102 Business Process Management Design Guide: Using IBM Business Process Manager
From these examples, it is clear that your wanted service maturity level impacts
your integration design considerations. Those considerations, in turn, can affect
your selection of IBM products. For example, the connectivity use cases can be
covered by products implementing the ESB pattern, where services composition
and business process orchestration can be covered by the BPM products.
104 Business Process Management Design Guide: Using IBM Business Process Manager
Use of AIS with web service binding
The integration service is simply made available as a web service. For IBM
Process Designer, it doesnt make a difference at this point whether the
web services are provided by an external application or by IBM
BPM Advanced.
Due to the loose coupling through web services, IBM BPM Standard and
IBM BPM Advanced are also free from deployment or versioning
dependencies. However, extra resource use might be caused by going
through the HTTP Server, possibly the load balancer, and serializations.
Which option should you chose?
In summary, SCA binding creates version dependencies, where web service
binding puts an additional load on the web server. It is important to evaluate
both alternatives thoroughly, and create a well-defined architecture decision
to create a common understanding of why either approach has been chosen.
Often, you can find yourself in a conflicting situation where you are required to
keep the licensing cost down, yet provide a larger, scalable topology.
We suggest that you review the IBM Redbooks publication Business Process
Management Deployment Guide Using IBM Business Process Manager V8.5,
SG24-8175, to help you choose the optimal topology that meets your budget for
licensing costs.
106 Business Process Management Design Guide: Using IBM Business Process Manager
3.6 Conclusion
In this chapter, we described the importance of high-level solution analysis and
design by laying out a sound foundation for your IBM BPM process solution.
Many of the practices described in this chapter apply equally to generic Java
Platform, Enterprise Edition (Java EE) applications (apps), in addition to IBM
BPM. However, we focus on aspects that typically do not receive adequate
consideration in actual practice. Also, we address IBM BPM Standard and IBM
BPM Advanced editions, although there are topics inherent to IBM BPM
Advanced that we consider to be out of scope for this book.
This chapter is not meant as an in-depth technical review of any one topic,
technology, or philosophy. IBM offers various training and consulting services
that can help you understand and evaluate the implications in your organization.
However, in many ways IBM BPM is not just another Java EE application. When
you look at an organizations existing software systems, you typically find
applications that are built for a single-purpose.
The successful attack and penetration of these applications can reveal the
process data, but it is hard to conceive of how such a breach might reveal the
actual business steps, decision points, or overall operational strategy of a
departments business functions.
110 Business Process Management Design Guide: Using IBM Business Process Manager
Figure 4-1 depicts a single-purpose application.
This is not true for IBM BPM, which encapsulates more than just process data.
IBM BPM process applications capture the very essence and details of a
departments way of doing business. IBM BPM provides easy-to-understand
flowcharts of process steps. These flowcharts show which employee groups are
entitled to execute particular steps, the decision points, and details of how those
decisions are evaluated.
They might also want to bypass security policies for their personal benefit (for
example, when claiming travel expenses).
112 Business Process Management Design Guide: Using IBM Business Process Manager
The most common security hole we see is an overreliance, or faith, in corporate
firewalls. It is very common to hear the phrase our IBM BPM network is internal,
so it is secured. Yet several sources have stated that most security breaches are
instigated from within an organization.
Rethink your attitude toward security. Even if you decide to trust 100% of the
employees who have access to your internal networks, can you be certain that all
actions they take are consistent with your security policies?
What about email or browser exploits, which could serve as an entry point to your
corporate network? What about no-charge software, which could include
non-trusted code?
What about CDs, DVDs, or Universal Serial Bus (USB) drives, which your
employees might insert into their notebook computers? What about external
consultants connecting to your corporate network? Can you ensure that 100% of
these devices have been thoroughly scrutinized?
Remember that there is no way that anyone can guarantee a 100% secure
environment. Notwithstanding, considering the issues that are detailed in this
chapter will, at the very least, eliminate the low-hanging fruit and drastically
reduce the universe of potential attacks against your IBM BPM systems.
Finally, the ways in which IBM BPM connects to external systems (web services,
message queues, and so on) differ depending on many factors:
Which IBM BPM product you are running (IBM BPM Standard or IBM BPM
Advanced)
Which version you are running (V7.5, V7.5.1, V8.0, V8.0.1, V8.5, and so on)
What type of integration you are describing (outbound versus inbound web
service calls)
All of these topics are addressed in detail in the IBM Redbooks publication IBM
Business Process Manager Security: Concepts and Guidance, SG24-8027.
114 Business Process Management Design Guide: Using IBM Business Process Manager
In addition to these generic questions, you also have to consider IBM
BPM-specific questions:
How many user repositories will the IBM BPM servers access?
Does each deployment environment support different user repositories?
The installation of your IBM BPM software, including the decisions surrounding
that installation, is one of the first steps in security. This is the foundation on
which your IBM BPM installations security relies.
With each new version of the IBM BPM software, these two disparate origins
become more tightly integrated. Portions of the software stack that served
Lombardis need to support a wide variety of Java EE application servers are
being replaced with more security-hardened IBM WebSphere counterparts.
Similarly, WebSphere Process Servers user interface (UI) has greatly benefited
from the joining of the two products.
IBM BPM is built upon, and is included with, WebSphere Application Server.
Many security tasks are best thought of from the perspective of WebSphere, but
others from the perspective of IBM BPM. Therefore, it is useful to spend a
moment to consider the terminology of the two perspectives.
The following list explains some of the important concepts in more detail:
Profile A set of Extensible Markup Language (XML) files and
application artifacts that describe and facilitate the
installation of WebSphere and associated Java EE apps.
Cell The overall security context for centralized management
of a WebSphere Application Server.
Node The virtual machine (VM) image (or hardware server) that
hosts Java application servers. Each WebSphere
instance can have multiple nodes.
App Server Java virtual machines (JVMs) where Java EE enterprise
applications execute. These are software constructs.
116 Business Process Management Design Guide: Using IBM Business Process Manager
Cluster A set of application servers, potentially distributed across
more than one node, that provide failover and
high-availability (HA).
Deployment Manager and Node Agents
Lightweight processes that keep the clusters in sync.
There is one Deployment Manager for each WebSphere
cell, and one Node Agent for each Node.
We have already seen that business process applications are developed within
the Process Center. The Process Center is also commonly referred to as the IBM
BPM development environment. When the process application authors are
satisfied with their current iteration of the process application, they can take a
snapshot of that process application and deploy it to another environment. This
next stage is typically called testing.
Among the benefits of this redeployment is that you separate the execution of the
process application from the dependencies that might have been present in your
companys development environment. Therefore, at a first glance you get the
chance to ensure that the process application has been bundled with all of the
underlying software and toolkits that it needs to execute.
When all parties are convinced that the process application is free of these
dependencies and is ready for wider distribution, it is then typically promoted to
another environment. This step is called staging or user acceptance testing
(UAT). The UAT environment is where a wider group of users is given access to
the process application. It is their job to ensure that the process application
satisfies all business requirements and is bug-free.
When the testing is complete, this staged application is eligible for promotion to
the production environment, with confidence that the application is ready for use.
The Deployment Manager is a WebSphere construct that doesnt map into the
IBM BPM lexicon, but the nodes are where the important part of the process
takes place. A node contains one or more servers, which are JVMs dedicated to
a specific set of IBM BPM tasks.
Depending upon the type of IBM BPM topology that you choose, each node
might have one - five servers that map directly to the IBM BPM concepts of
AppTarget (where the IBM BPM runtime engine executes), Support (which is
where the IBM BPM Performance Data Warehouse executes), and others. These
servers are then clustered together across node boundaries.
118 Business Process Management Design Guide: Using IBM Business Process Manager
In this diagram, we have named the cells according to their role as
deployment environments:
bpmDevCell This cell contains the IBM BPM Process Center and
central development repository. This deployment
environment is often referred to as development, PC, or
the dev environment.
bpmTestCell This cell contains an IBM BPM Process Server runtime
deployment environment. This environment is where
process application authors can ensure that their process
applications are free from any dependencies upon
development tools or artifacts. This deployment
environment is often referred to as testing.
bpmStageCell This cell contains an IBM BPM Process Server runtime
deployment environment where process application
stakeholders can ensure that the process applications are
isolated completely from the development environment.
Typically, the staging environments closely mimic the
production deployment environment.
The environments are similar because the expectation is
that when the staging testing is completed, the process
applications can be installed into production environments
with no issues. This deployment environment is often
referred to as staging or UAT.
bpmProdCell This cell contains an IBM BPM Process Server runtime
deployment environment where process applications are
deployed for use in the enterprise. Often, these
environments are behind strict firewalls, and have special
deployment considerations. This deployment environment
is often referred to as prod or production.
These distinctions between test and staging are largely superficial. There is no
difference in functionality between them. Often, organizations have distinct ideas
about how test and staging are treated. Some organizations incorporate yet
another stage environment, called pre-production.
This is not a strict requirement, but simply an example. IBM BPM and
WebSphere enable a great deal of flexibility in how you define your IBM
BPM environment.
For more information about this topic, see the IBM Redbooks publication IBM
Business Process Manager Version 8.0 Production Topologies, SG24-8135.
Complex realities
However, actual environments are rarely as orderly as the example in the
diagram in Figure 4-5 on page 118. The complications multiply when you
consider the environment into which IBM BPM is being deployed. Each IBM BPM
deployment environment typically has the following components:
Its own database server
A front-end web server
Hardware load balancers
Single sign-on (SSO) solutions (which might also be hardware)
Servers that host web services
Any number of corporate enterprise information system (EIS) servers
120 Business Process Management Design Guide: Using IBM Business Process Manager
An example IBM BPM deployment environment is depicted in Figure 4-6.
All of these components communicate with each other, and each line of
communication introduces another touch point that needs to be scrutinized from
a security point of view. Complexity breeds fragility, which in turn breeds
opportunity for exploitation.
The antithesis, of course, is simplicity. But how can you achieve simplicity when
faced with so many product components, each one speaking to another over
different protocols?
Can you trust with 100% certainty that your firewall vendors will never release a
software update that has a security hole in it? How often is your notebooks
operating system updated with security fixes?
The simple fact is that many studies, from Gartner, Ponemon, the US Federal
Bureau of Investigation (FBI), and others, have determined the following facts
about security:
The majority of attacks originate from within.
The attackers identity is rarely known or discovered.
Security breaches are equally likely to be caused by employees as by
external agents.
An overwhelming majority of attacks are the result of an exploitation of a
misconfiguration, or a failure to follow leading practices.
122 Business Process Management Design Guide: Using IBM Business Process Manager
Security breaches do not have to be the result of malice. They could be the result
of simple, honest mistakes. But in the end, the intent does not matter. The
security breach occurred, and you must deal with the consequences.
Is it safe to believe that not one of your employees would ever steal data?
The problem we face with hacker activist (hactivist) groups like Anonymous is
that they are, in fact, anonymous. Until an arrest is made, these people remain
nameless. Estimates on the number of arrests (and therefore name disclosures)
as a percentage of security attacks are hard to come by.
However, it is reasonable to assume that more attacks occur than arrests. This
leaves us with the realization that most security breaches are instigated by
individuals who remain anonymous. They could be anyone.
Furthermore, even if you choose to trust that there is not one employee within
your ranks who sympathizes with hactivists, can you ensure that 100% of your
employees always follow corporate security guidelines? What about email or
browser exploits that could serve as an entry point to your corporate network?
What about CDs, DVDs, or USB drives that your employees might insert into
their notebooks? Can you ensure that 100% of these devices have been
thoroughly scrutinized?
The bottom line on firewall security is this: It is necessary, it is very helpful, but it
is not a stand-alone solution to enterprise security. Firewalls are necessary, yes,
but they are not sufficient.
Our goal is to secure each touch point, ensuring that the low hanging fruit is
eliminated, thereby radically reducing the potential number of attackers by
simultaneously increasing the skills required to exploit a security hole.
Note that the Protocol defaults to http://. During Process Server startup, the
runtime environment uses this information to communicate back to the Process
Center, notifying the Process Center of the runtime Process Servers availability
to receive deployments of process application snapshots. This communication
between Process Server and Process Center includes a URL, a user account,
and the corresponding password.
124 Business Process Management Design Guide: Using IBM Business Process Manager
If you do not take the extra step to specify the https:// protocol in the preceding
figure, you will be sending your IBM BPM administrator account name and
password in clear text. There is simply no substitution for taking the time to
ensure that all IBM BPM product components communicate with each other, and
with all external systems, over Secure Sockets Layers (SSL).
Using a DMZ
We advise that you install the web server or reverse proxy physically in front of
the WebSphere clusters. Specifically, the web server or reverse proxy server
should be installed on a physical server that sits between two firewalls, in what is
commonly called a DMZ.
The outer firewall enables only SSL port traffic (typically 443, but this can be
customized). The web server or reverse proxy server then communicates with
the IBM BPM servers over a different SSL port through the inner firewall.
Encryption in the client is very rare. Typically, you want the server to work with the
data, so the server needs the data in clear text.
Perhaps even more important is that you cannot know with absolute certainty
what percentage of your data might be cached somewhere within the IBM BPM
database tables. This caching effectively nullifies your encryption.
A more complete description of these topics can be found in the IBM Redbooks
publication IBM Business Process Manager Security: Concepts and Guidance,
SG24-8027.
126 Business Process Management Design Guide: Using IBM Business Process Manager
SSL certificate host name verification
More recent versions of the IBM BPM applications (including V8.0 and later)
include extra hardening steps that were not present in previous versions. For
example, previously, it was possible to create the IBM BPM profiles using
localhost as the name for the BPM server.
There are many scenarios where BPM talks to itself (heartbeats, deployment of
process apps from Process Center to Process Servers, the WebInspector REST
facade, the federated Representational State Transfer (REST) application
programming interfaces (APIs), and so on). The product now requires that the
host names of each part of these communications match the names in the
SSL certificates.
In general, we advise that great care should be taken to ensure that the
certificates common name (CN) matches the actual fully qualified name of the
IBM BPM servers.
4.3 Authentication
Authentication is the process of proving the identity of the user who (or even
another computer system that) is requesting access to software. The most
common type of authentication is, of course, the user ID and password. However,
there are other methods of authenticating to a server.
In light of recent research showing the high incidence of security attacks that
originate from employees or contractors, the choice of how users authenticate to
your corporate systems should be evaluated carefully. Often, the choice of how
users authenticate to corporate systems is decades old, and it might well be
worth reviewing the policies at your organization.
First, a word about repositories and registries. These two terms are often
confused. A repository is a concrete set of items (in this case, the list of user
accounts). A registry is a reference to something (in this case, the repositories
within the user registry). It might be helpful to visualize this as an analogy: A
librarys card catalog is a registry, and the librarys stacks of books is a repository.
128 Business Process Management Design Guide: Using IBM Business Process Manager
You can configure WebSphere Application Servers user registry to use any of
several authentication mechanisms:
A flat-file repository (not recommended)
A corporate LDAP repository (most common)
A set of corporate LDAP repositories (enables complexity)
Windows Integrated Authentication, such as Simple and Protected Generic
Security Services API Negotiation Mechanism (SPNEGO) or Kerberos
SSO (very popular), including CA SiteMinder, IBM Access Manager, and
Security Assertion Markup Language (SAML)
The flat-file repository is not intended to scale beyond 200-300 users, but it does
provide usefulness even in large-scale production environments, where it might
be wanted to maintain the BPM administrative accounts locally, so that the BPM
environment can be administered in the case of a failure to reach the
main repository.
Often, corporate LDAP systems are considered the system of record for
employee data. Because of this, LDAP administrators are typically very careful
about what type of data should be stored in the LDAP. This is an important
consideration for using an LDAP with IBM BPM. Every IBM BPM user has an
inbox that receives business process tasks during a typical work day.
130 Business Process Management Design Guide: Using IBM Business Process Manager
However, even in an organization whose IBM BPM adoption is mature, where
potentially every employee listed in the corporate LDAP might share this same
requirement, still it is not a good idea to store the inbox or process application
task lists in the LDAP. Even though they all share the same requirements, the
tasks themselves vary from person to person, and will most likely require
updating several times per day. This requirement violates the LDAP concept.
In each of these cases, the presupposition is that the individual employees are
not likely to change their group affiliations frequently. Therefore, this information
is appropriate for an employee system of record, such as the LDAP repository.
Figure 4-9 depicts a very simple case of one federated registry consisting of one
flat-file repository and one LDAP repository. As mentioned before, WebSphere
Application Server is compatible with various LDAP vendors products.
Each LDAP vendor might define a different reserved word to access a particular
function, but the IBM BPM VMM can be configured to abstract these differences
and therefore work with any LDAP server that is LDAP V3-compliant. WebSphere
Application Server also includes several LDAP templates to facilitate installation.
132 Business Process Management Design Guide: Using IBM Business Process Manager
It is equally common for clients to have more than one LDAP server. This is often
the case due to acquisitions or geographical dispersion. The acquired companies
might well have a host of software systems that rely upon their existing LDAP
structures, and there is always a period of integration where old systems are
updated or replaced. WebSphere Application Server enables this by federating
LDAP repositories together.
Figure 4-10 shows an example where the VMM federated registry is composed
of a single flat-file repository, one generic LDAP V3 server, plus a series of
Microsoft Active Domain repositories arranged in a tree structure.
There are several reasons for this, but chief among them is that the WebSphere
Application Server security mechanisms are initialized and enabled well before
other WebSphere Application Server services, such as data sources and
enterprise beans. There is, therefore, a great deal of software that you need to
write on your own, effectively reinventing the wheel.
134 Business Process Management Design Guide: Using IBM Business Process Manager
Figure 4-11 depicts the actual network communications as captured by the
freeware network protocol analyzer, WireShark, during the normal boot-up
process of the IBM BPM Process Center.
If you have never used a network packet analyzer before, all you need to know for
the purposes of this example is that each line is a summary of the Transmission
Control Protocol/Internet Protocol (TCP/IP) traffic. You can watch this list in real
time. The lower portion of the panel here is showing the contents of the selected
TCP/IP packet.
This highlighted summary clearly shows that this packet is an LDAP bindRequest
on the account uid=admin, ou=system. The packet is a request to bind the IBM
BPM servers to the LDAP database to make a query. If you know the account
name and password used to bind, you can browse the LDAP for any information
that it contains. You can see, in the packets content area, that the password for
this account is secret.
Unless you secure your LDAP server using encryption (SSL), you are leaving
your corporate LDAP server open to browsing every time an IBM BPM user logs
in to their /portal Inbox.
Many SSO technologies rely upon cookies or HTTP headers to carry the users
credentials with each HTTP request. Often, these credentials are encrypted.
Unfortunately, the fact that these credentials are encrypted does not matter. An
encrypted header can still be sniffed, copied, and injected into an attackers
browser HTTP requests.
The fact that the human attacker cannot read the contents of the encrypted
header in no way diminishes the opportunity for attack. She can just paste the
contents of this encrypted header into her browser, thereby impersonating the
original SSO credentials.
What must occur for any SSO solution to be considered secure is that the
destination server must take the extra steps to ensure that the SSO headers
originated from a known good, trusted server. Simple strategies like inspecting
the IP address of the HTTP request are not sufficient. IP addresses (as in this
case) can be spoofed.
136 Business Process Management Design Guide: Using IBM Business Process Manager
The correct, proper, and secure implementation of an SSO solution employs a
mechanism for ensuring that the origination of the SSO credentials is valid,
thereby eliminating the type of injection attack described previously. This is
especially true if you are writing a custom trust association interceptor (TAI) to
integrate an in-house developed custom authentication system into the
WebSphere Application Server security mechanisms.
As you can see, this is deceptively simple. Six methods, two of which are simple
get() functions that return (typically) hard-coded strings. Two more are just
initialize() and cleanup() functions. This leaves us with only two methods to
do the heavy lifting.
It is very common for us to see software developers celebrate that final change,
which ultimately allowed their SSO solution to function, by simply moving on to
the next overdue project task. However, it is not enough that your SSO solution
works. It must work securely. This is another common security hole that we see:
An in-house developed TAI that fails to take the additional step of ensuring that
the origination source of the SSO header comes from a trusted source.
4.4 Authorization
Authorization is the process of ensuring that a user (or other computer system)
has permission to perform a given act.
For example, Microsoft Active Directory returns only the first 4,500 users or
groups, truncating the rest from the results. This can obviously cause havoc for a
business process application that simply uses LDAP groups for its authorization.
138 Business Process Management Design Guide: Using IBM Business Process Manager
In addition, because LDAP products are optimized for read-only and static data, it
is very common that the structure and content of the LDAP repository be under
the strict control of an LDAP administration team. Furthermore, these groups
might have been defined for existing applications. It is not uncommon for these
existing applications to no longer be in use, and yet their LDAP groups remain.
This can be contrary to the core value proposition of IBM BPM.
One of the most significant benefits of IBM BPM is its ability to model business
processes to gain some perspective and, hopefully, to use this to effect business
process improvement. The entire approach to IBM BPM, from process
documentation, to process application development, to process improvement, is
based on agile principles.
It is quite common for a team of process designers to decide that a process can
be improved if the roles are reexamined, possibly creating new roles and
combining others. To rely on the LDAP administration team to make these
changes to the corporate LDAP is almost always untenable from both
perspectives:
The process designers want immediate turnaround.
The LDAP administrators need to ensure that changes will not break other
enterprise applications that rely on the LDAP structure.
To address this concern, IBM BPM goes much further than simply referring to
LDAP groups. IBM BPM provides a product component called the
/ProcessAdmin, and this component has a section called Group Management.
Within this section, business process designers can create groups that go
beyond what is presented by the corporate LDAP.
Consider the case where an organization might have grown as the result of
acquiring a competing company in a different geographical region. Each region
would have almost certainly had different LDAP structures.
Perhaps region 1 called their IT department ldapIT, and region 2 called theirs
adBPMDevelopers. IBM BPM enables a unified view of these two LDAP groups
under a single group called, for example, devAuthors.
This is a very powerful feature. LDAP browsers are not typically capable of
merging two LDAP sources to provide a unified view. In Figure 4-12, you can see
that the two LDAP groups are combined in devAuthors. Furthermore, another
user has been added to devAuthors. When the business process executes, any
user who appears in devAuthors is eligible to perform this business task.
In addition to combining two groups into one, IBM BPM also enables the
inclusion of groups within groups (nested groups). Therefore, the entire
management of the groups is handled by the business process designers and
SMEs. These professionals are not bound to the LDAP administrator
organization, because all of this grouping information is in IBM BPM.
Another important point that is worth considering about your business analysts
(BAs) taking control of the BPM groups is that the corporate LDAP groups might
have very little, or absolutely nothing, to do with the business processes that you
are currently modeling.
140 Business Process Management Design Guide: Using IBM Business Process Manager
In the diagram in Figure 4-12 on page 140, the simple fact that ldapUsers 7 and
8, and adUsers 8 and 9 are all considered developers tells you nothing about
which applications they should be granted access to. Perhaps ldapUser7 is
working on a highly confidential application that only he should have access to.
Going to the LDAP administrator organization to request a new group just for
ldapUser7 is unwieldy at best. The /ProcssAdmin component gives your business
process designers and SMEs control of your business group authorizations.
Proper group management: We advise that you ensure that your groups are
tightly coupled to the business process functions. Use /ProcessAdmin to define
groups, and use LDAP groups rarely.
Although Participant Groups have been deprecated with IBM BPM V8.5, old
definitions are 100% compatible with, and automatically migrated to, BPM V8.5.
Teams introduce three new major features:
Teams can now have Managers (identified and modeled within IBM
Process Designer).
Teams can now be specified dynamically (with the members being
determined by a web service call).
Teams can now be refined dynamically (with non-applicable team members
now being filtered away).
You define teams in IBM Process Designer as a part of a process application (or
even a toolkit). You can specify that teams be one of two types:
Static. All users are defined using either LDAP groups or /ProcessAdmin
groups in the same way that Participant Groups had been defined.
Dynamic. All users are determined at run time using a Team Retrieval
Service.
Team Retrieval Services can be built using the IBM BPM JavaScript API,
or they can be built as standard Integration Services. The JavaScript API
provides functionality identical to that found in the /ProcessAdmin group
management component.
As you can see, IBM BPM defines a very fine-grained authorization model, and
does so in product-specific terms (for example, you are not authorized to run this
task if you were also the last user to update this task). This is a strong argument
for not simply considering the groups defined in your corporate LDAP as a
source of user authorization.
For a more complete description of these topics, see IBM Business Process
Manager Security: Concepts and Guidance, SG24-8027.
142 Business Process Management Design Guide: Using IBM Business Process Manager
4.5 Conclusion
In this chapter, we described the importance of security to, and the hardening of,
your IBM BPM installation.
We described how IBM BPM and WebSphere Application Server concepts map
to each other, and identified specific hardening steps, including the use of SSL,
DMZs, and database security.
We described user and task authorization, how IBM BPM enables fine-grained
groups that identify the set of individuals who should be allowed to execute
specific tasks within a business process, and how these teams can be defined
dynamically at run time using web services.
146 Business Process Management Design Guide: Using IBM Business Process Manager
5.2 Business process design
In this section, we describe different types of business processes, such as
structured and unstructured ones, and give you an overview of patterns and
anti-patterns for process design.
With any business process, we want to consider the following points to determine
whether what we have is a viable business process:
Performing the process provides value to the business.
The process contains individual business-relevant steps.
Business-relevant data flows through the process.
The process follows a relatively structured path.
The steps within the process are performed by multiple roles or teams.
The process changes over time as a result of changes in the business.
If the previously mentioned factors are not given, you might want to rethink your
decision whether to implement your requirements as a business process, or use
a different approach.
The key to structured processes is that they have the following characteristics:
Measurable
Comparable
Repeatable
We address more details about the process types in the following sections:
Structured processes
Generic process model
Unstructured processes
148 Business Process Management Design Guide: Using IBM Business Process Manager
Process automation
Besides the process types, there are different levels of automation for each
process, as shown in Figure 5-1.
The answer to both is not in the process model, although this is often done
incorrectly. Next, we look into why this is the case.
1
More information about the American Productivity and Quality Center can be found at:
http://www.apqc.org/
150 Business Process Management Design Guide: Using IBM Business Process Manager
Additional information about this topic can also be found in the IBM Redbooks
publication Process Discovery Best Practices Using IBM Blueworks Live,
REDP-5111.
Figure 5-2 shows how Level 4 processes belong in the business process layer,
where Level 5 processes are part of the consumer layer.
In a process model, we always stay above Level 5. Page flows (or page
navigation) and service orchestration are part of the definition of the task (not the
activity), and are therefore modeled differently.
Rule: If you have a sequence of more than one activity in a row in one
swimlane, chances are that you mixed up different levels of process design.
Multiple steps in the same swimlane of a process diagram imply that they could
have been performed by the same entity (system or person) in one activity.
152 Business Process Management Design Guide: Using IBM Business Process Manager
Why does it make sense?
Using swivel chair integrations or automations, you can track, compare,
measure, prioritize, and complete many more tasks using IBM BPM features.
Only the integration has to be done manually. Because integrations are
usually drivers of implementation effort and time, it helps you to deliver
value faster.
2. Linked external window with request context is similar to Assisted Swivel
Chair, with the addition of a link to the external application where the action
has to be performed. The link already contains case-related information, so
the fields in the external application are pre-completed as much as possible.
For example, the task contains a link into the SAP system that opens the
page where you need to update the clients information. All address
information has been completed automatically, but the user has to log in
manually and might have to complete some additional information.
Why does it make sense?
Similar to 1) with the difference that the user does not have to know where to
perform the action.
3. Linked external window with request context and callback is similar to 2), with
the addition that the external system can notify IBM BPM about the results.
For example, the IBM BPM task contains a link to the SAP system to update
the clients address. Upon selecting that link, SAP opens, the user has to log
in, and the update client information window displays with all of the address
information completed automatically. The user simply has to select Submit,
and SAP notifies IBM BPM through callback if the update was successful.
The IBM BPM Coach now contains a status message update successful.
Why does this make sense?
This is a simple and fast way to create an integration without causing too
much duplication of work through swivel chair activities.
4. Integrated linked external window is similar to 3) with the difference that the
external application does not open in a separate window, but is directly
integrated into the IBM BPM application. From a user perspective, it looks like
one single application.
For example, the IBM BPM task includes a user interface (UI) to change the
client information. All the user has to do is to submit it in the Coach. The SAP
update client information UI is opened there.
Why does this make sense?
From a user experience point of view, this feels fully integrated.
154 Business Process Management Design Guide: Using IBM Business Process Manager
Patterns, anti-patterns, and modeling risks
Basic information about process patterns can be found on the following website:
http://www.workflowpatterns.com
These patterns are to be considered basic process flow patterns. As you read
through the website you discover that in the product evaluation section for each
pattern, there is a scoring for BPMN and BPEL whether it is supported in the
particular functionality.
Before we go into the details of how to model a process, and which patterns are
good and which are not, we have to ask ourselves questions to determine
whether this is a process at all.
If it is not a process, it is most likely a service that you want to manage using your
service-oriented architecture (SOA) governance. In case the outcome is that this
service should still be implemented within IBM BPM, the following
implementation options must be considered:
Expose as IBM BPM Standard service
Services in the IBM BPM Standard Edition can be exposed in different ways.
In this case, exposing it as a Human Service or Startable Service makes the
most sense.
Exposing as a Human Service means that it can be started and executed by
an individual, either through the process portal or a link. The service is
non-persistent. Therefore, if the user abandons it, information is lost, unless
that information is manually saved to a system of record (SOR).
Typical cases, where human services without process context are exposed,
are simple maintenance services, such as create, retrieve, update, and delete
operations to a database.
Exposing as a System Service means that it can be called by other systems.
The other systems can be other process instances or even external
applications. System services can be exposed so that they can be called
either through web services (SOAP over HTTP) or Representational State
Transfer (RESTful) protocol services.
156 Business Process Management Design Guide: Using IBM Business Process Manager
Consider the following situations as they apply to the Rule of Seven:
When to use?
The approach should always be used.
When not to use?
The approach should always be used.
For more information, see Divide and conquer business processes on
page 163.
Escalations
Escalations are important to ensure that SLAs are held, or to react or report
upon the breaking of them.
As indicated previously, SLAs do not contain any functionality to ensure that
they are being met. In IBM BPM, the purpose of SLA consequences is to
either report and react upon their breaking after they were not met.
Consider a task that has an SLA that defines that the execution time must not
be longer than one day. However, nobody executes the task for two days, yet
still nothing will happen. Only after the task has been completed is the SLA
evaluated, and the defined consequences are triggered.
To create escalations that serve the purpose of ensuring that an SLA is being
held, we suggest using timer events. The most common use is to attach a
timer and reroute the task to itself while changing the assignment logic to the
next higher lever in the management chain.
Another common pattern is to escalate to a separate task for a manager to
make sure that whoever has the task currently assigned either executes it or
reassigns the task to another member or group.
158 Business Process Management Design Guide: Using IBM Business Process Manager
Having a multi-instance loop (MIL) in the system lane is the same as having n
number of tasks in a sequence. Particularly when talking about the system
lane, the string of pearls anti-pattern can have a tremendous effect on the
performance of the system. The effect even multiplies if the activities are MIL
sub-BPDs or sequential or nested sub-business process definitions (BPDs)
that are of system-centric nature.
If a process spends a significant amount of its time paused on one step, and
during this time there are many interactions with the process data, it is likely
that we have reached a natural process end state.
160 Business Process Management Design Guide: Using IBM Business Process Manager
For more information about process lifetime considerations, see Divide and
conquer business processes on page 163.
Event-driven processes
We use events in a process if we only need to know that it will be done, not
that it has been done.
Messages are placed in several queues within a single transaction:
This action is useful for updates to systems that are not expected to be
instantaneously up to date, such as data warehouses and audit logs.
This action is useful for notification type requests, such as Short Message
Service (SMS), email, and so on.
Event-driven processes provide the following benefits:
They provide a fast answer to the caller.
With persistent queues, the messages should never be lost, and will be
applied to their destinations eventually.
Event-driven processes pose the following challenges:
Destination systems have not received the data when the response
is given.
The time taken for destinations to receive the update is not in the control of
the composition.
Should problems occur while processing the messages, the composition
and therefore also the caller are unaware of them. Event-driven processes
are reliant on external exception handling.
Consider the following situations as they apply to event-driven processes:
When to use?
Use this approach if you dont need to know the result immediately.
When not to use?
Do not use this approach if you need to act (for example, make a decision)
based on the response of a call.
Multiple system swimlanes
A system swimlane in a business process defines what the IBM BPM system
is doing. It does not define the systems that it is integrating with. Therefore, a
process can always have a maximum of only one system swimlane.
162 Business Process Management Design Guide: Using IBM Business Process Manager
Consider the following situations as they apply to exposed services initiating
the processes:
When to use?
Use this approach when there is a chance that users who initiate the
process will end their activity and simply close the browser (abandon
the instance).
Use this approach if the start of the process does not happen through the
IBM BPM Process Portal, so that if a process was started and a task
created, the user is not able to resume the task (for example, a form that is
available on an Internet page).
When not to use?
Do not use this approach if the initial task takes a long time, and it is
expected that the user can jump in and out of the human service as he
completes the task.
In short, breaking down a process into more atomic pieces can be done
through different levels of decoupling. In any case, at the end there remains a
master process that controls the complete process instance lifecycle. This is
depicted in Figure 5-7.
164 Business Process Management Design Guide: Using IBM Business Process Manager
If so, the respective process gets instantiated and executed until it reaches
the next long waiting point. This activity is depicted in Figure 5-8.
This IBM Redpaper publication can provide more detailed information about how
this can be achieved with ad hoc processes.
166 Business Process Management Design Guide: Using IBM Business Process Manager
The following list include some of the advantages of this approach:
Instant availability of processes
No development lifecycle, no change management, and no negotiations with
the information technology (IT) department are necessary. The configuration
platform is provided to the line of business (LOB), which can model processes
as they want. Making it available for execution after it has been configured
happens with the push of a button.
Reporting and visibility
Reporting and measurement, tracking of KPIs and SLAs are possible in the
same way that it works with a standard BPMN process application.
Increase of return on investment (ROI)
The initial investment (for example, in license, platform and services) into your
IBM BPM initiative is returned much faster, because the generic approach
does not deliver only one process, but potentially hundreds of processes.
Although there is much value to the generic process approach, there are also
some limitations:
Integration
Integration with an SOR, rules, or other services is generally possible.
However, integration is only reasonable if a large number of processes that
are expected to run on the generic platform require those. To support a
generic process model, you need to have well-defined and standardized
object models and interface definitions.
Complexity
A large variety of process flow patterns can be applied, but not all of them.
The intent of a generic process pattern is to support low-complexity
processes.
Automation
The generic process pattern solely supports human-centric processes with a
low level of automation. The intent is to implement process flow automation
(see Process automation on page 149) as opposed to task automation.
Unstructured processes
A non-structured, or unstructured, process can be defined as a process where
each instance of the process differs from another instance by its execution path
and its lifetime. Process improvements cannot be easily, or at all, identified for a
non-structured process.
The IBM BPM case management system can simplify the job of designing and
building cases. It also provides a graphical user interface (GUI) for caseworkers
to manage cases. With IBM BPM, you design a case management application
that is based on closely related cases, and then deploy that solution into a
production environment. Caseworkers can then complete work items that are
associated with cases.
For example, if you want to design an application for resolving credit card
disputes, IBM BPM provides tools to design and create an application that the
caseworker can then use to process the cases that are created.
IBM BPM unifies information, processes, and people by providing you with the
following functions:
An active-content infrastructure that manages the persisted case object
model and enables content-based events for case activities. For example, the
addition of a document or a field change triggers a case activity.
Enterprise Content Management (ECM) integration that includes complete
document lifecycle capabilities. These capabilities include creating a version
and security. Some licensing restrictions might apply.
True content management functions to store document metadata that you can
modify and search on.
A process that manages the logic for running a sequence of activities.
A flexible and customizable UI that is ready for immediate use. You can use
the UI to create a team-based experience that can provide caseworker with
the information they must work on.
Case types define the activities, and might use document types to support the
activity. Case types also specify the teams (human services) that must complete
the activities to solve a business problem. The case type also includes properties
that are shown to a caseworker in the IBM BPM Process Portal. Case types
make up a case management application. A case is an instance of a case type.
168 Business Process Management Design Guide: Using IBM Business Process Manager
Figure 5-10 provides an overview of the structure of the IBM BPM basic case
management feature.
Consider the following scenario. The activities are unordered because the
sequence of activities is unpredictable. The events determine the order in which
the activities in the process are followed. People rather than programs interact to
resolve the dispute. External documents are needed for verification. In this
scenario, a case would most likely be your implementation choice.
Consider another case scenario that handles credit card billing complaints. The
activities are not wired. No predetermined sequence is set at development time.
A worker would likely start by describing the complaint, and finish by resolving
the dispute. However, whether the worker receives the client information before
the vendor information would likely be determined by what data the worker
receives in the complaint.
The information that is retrieved about the client determines whether the worker
checks with the people who handle the client records. The information that is
retrieved about the vendor determines whether the worker checks with the
people who handle vendor records. The information that is retrieved about either
the client or the vendor might lead to investigating the computer billing system
for problems.
People who interact with other people, rather than automated programs,
determine the activities. To verify the complaint, receipts and invoices (which are
external documents independent of the case) must be captured. To implement
these activities with human services, subprocesses, services, and teams, you
use the same set of tools as you do to implement a business process.
Figure 5-11 outlines the BPM basic case management activities design for a
credit card billing complaint system.
170 Business Process Management Design Guide: Using IBM Business Process Manager
Key differences between BPM and case management
You can define an ordered sequence of activities that You can define an unordered set of activities that
can be completed to solve a business challenge. can be completed to solve a business challenge.
The sequence of activities is stable and seldom The activities occur in an unpredictable order.
changes. The process is predicable and repeatable.
The process determines the events. The first activity The events determine the process. As events
determines the first set of events, which then leads to occur, a worker selects the appropriate activity.
the next activity and the next set of events. The The resulting process can vary depending on
activities are wired to one another, which determines the current event and the subsequent selection
the sequence. by the worker. Activities are not wired to each
another.
The activities are often programmatic. A repeatable People primarily determine the activities.
sequence, such as selecting a set of potential credit Handling a client with a billing error is done by a
card owners from a database, can be automated. person who uses judgment to determine the
best resolution of this particular case.
External documents are not an essential part of External documents play a key role. For
the process. example, receipts provide a record for how the
problem that must be resolved began.
One example everyone is familiar with, is supermarket check-out lines. The most
commonly used system is that buyers line up at any line they like. This can be
compared to the push pattern. Work (a cart full of items) gets pushed to a
particular system or user (the cashier) to be completed.
This is exactly where inefficiencies come into play. Many supermarkets have
realized that this effect can cause frustration with their clients, and they optimized
their check-out system, from a push pattern to a pull pattern.
Using the pull pattern, there is only one single line for all registers. As soon as a
cashier is ready for the next client, he indicates this, the client moves forward and
proceeds with the check-out. Although the line appears longer, the overall
checkout time has been proven to be shorter and therefore more efficient.
Figure 5-12 illustrates the supermarket example with the push versus pull model.
172 Business Process Management Design Guide: Using IBM Business Process Manager
Pull
Pull correlates to the supermarket example where we have one line for
all registers.
In the context of IBM BPM, pull means that activities get assigned to a group of
people (team) rather than the individual (user). Everyone in the group is allowed
to execute the task. As soon as someone starts the task, it gets claimed, which
means, that this task is only visible and available for this one person. Nobody
else can work on it. If we now make sure that the queue of work items is
prioritized, we have a very efficient way to work on tasks with a group of people.
Push
Push correlates to the supermarket example where people line up at the register
with the shortest line.
In the context of IBM BPM, push means that activities get directly assigned to an
individual (user). The assignment can be based on many different factors,
including but not limited to the following options:
Number of open work items
Priority
Round Robin methodology
Shortest estimated completion time
Attribute-based routing
Attribute-based routing can be applied for push and pull systems. In both cases,
the user information includes attributes that are used for filtering. The following
list includes some of the more often-used attributes:
Language
Skill
Department
However, other attributes are possible as well. Using these attributes as routing
criteria, so-called dynamic groups are created inside IBM BPM. Note that
dynamic groups are not editable through the process admin console.
In the pull system, the user attributes are used to create the group of users that
receive the task. In the push system, the user attributes plus additional routing or
distribution information (such as load-balanced, round robin, or others) are used
to assign a task directly to a particular user.
The larger services are, the harder they are to understand. This may sound
trivial. However, try to apply the following rules (they are not hard rules) to make
it easier to reuse your services and change code artifacts:
Never copy and paste
If you are about to copy and paste something, do not do it. Put it in a service
and reuse it.
Do not cross lines
If you cross lines, you most likely reach a complexity that is worth breaking up
into smaller pieces. Also, do not forget the Rule of Seven (as described in
Patterns, anti-patterns, and modeling risks on page 155).
One Coach per service
If you have many Coaches within one service, all the navigation, data
initialization, and validation can cause much inconvenience for anyone who
tries to change the service. Wrap the Coach into a separate human service.
You might want to reuse it stand-alone anyways.
With anything that you are implementing, always remember that you potentially
want to reuse it. Avoid large JavaScript blocks, because JavaScript (client-side
and server-side) is interpreted at run time and therefore slower to process than
compiled artifacts, such as Java code. Large client-side JavaScript blocks can
also produce very large Document Object Model (DOM) trees, which are
expensive for browsers to process and render.
Finally, large JavaScript blocks are often indicative of too much logic being
placed in the IBM BPM layer. As a general guideline, limit a JavaScript block to
50 lines. If your implementation exceeds this value, reevaluate the design and
refactor the implementation to use smaller JavaScript blocks.
174 Business Process Management Design Guide: Using IBM Business Process Manager
5.3.2 Human service design
The IBM Coach Framework is a key element of the IBM BPM product suite. With
the Coach Framework, process authors can create and maintain custom
web-based UIs that are embedded in their business process solutions. This
ability to create and maintain custom UIs is a key factor in the successful
deployment of business process solutions.
There are several design considerations that you should remember when
working with Coaches. This section covers the following topics:
Client-side versus server-side human services
Coach View design
Responsive design
For a more detailed description about how to build Coaches, see the IBM
Redbooks publication Leveraging the IBM BPM Coach Framework in Your
Organization, SG24-8210.
IBM BPM 8.5.5 introduced the new client-side human services. With the new
client-side human service, the service is downloaded to the browser and
executed. When a Coach is encountered in this case, it is rendered in the same
browser. Client-side coaches provide the following key benefits:
Enable the use of client-side capabilities, such as client-side validation.
Help offload the server by executing services in the local browser.
Reduce the communication between the browser and the server.
Reduce the number of server requests and size of data on Coach transitions.
Reduce server-side resource use (more concurrent users with less
performance effect).
Supported Coach types Available for both new Available for new Coaches
Coaches and heritage only (heritage Coaches are
Coaches not supported)
Usage of JavaScript Server scripts that use Client-side scripts that use
server script syntax standard JavaScript syntax
176 Business Process Management Design Guide: Using IBM Business Process Manager
By using the Coach Framework in IBM BPM with atomic and composite Coach
views, you have many possibilities to create UIs that meet your business needs
the best.
As you design your Coaches, you have to consider the implications or trade-offs
that the design includes. The two most prominent considerations are
performance and business agility:
Performance
Generally speaking, the older the browser you are using and the more
complicated the Coach UI, the longer the Coach will take to render. The
following specific issues affect performance:
Large DOM trees
Business objects that are bound to Coach views, such as
industry-standard schemas including Association for Cooperative
Operations Research and Development (ACORD) for insurance, Health
Insurance Portability and Accountability Act (HIPAA), and so on, are
persisted when boundary events occur.
This can be a costly operation, especially for large businesses. if the
business object used in the process flow is large and complex, you can
reduce this cost. To do so, create a separate business object that only
contains fields that are relevant to the Coach UI, and bind that business
object to the Coach View.
Large JavaScript scripts
Deeply nested Coach Views
For better performance, make as few network requests as possible to the
process server. This is particularly important if the runtime environment has
high network latency, or if it uses a relatively low-bandwidth network.
The following techniques minimize network requests:
Combine multiple JavaScript and Cascading Style Sheets (CSS) files into
one (or a few).
Design coarse-grained API calls that minimize the number of API calls
that flow over the network.
Perform create, retrieve, update, and delete operations to external
systems of record (SORs) before or after the Coach, rather than
using Ajax.
178 Business Process Management Design Guide: Using IBM Business Process Manager
Responsive design
Responsive Coach Views can adapt to different form factors in a flexible way. You
can build UIs that are responsive to a users runtime environment by using the
new responsive settings for Coach Views available with IBM BPM V8.5.5. You
can configure properties, such as visibility, formatting, or presentation style, for
different screen sizes. Therefore, you can design one interface that changes in
appearance and behavior based on the users screen size.
The same code is rendered on IBM Worklight mobile applications, default IBM
BPM Coaches, mobile browsers. The code can even be embedded in other
applications, such as IBM Notes and IBM Connections.
Figure 5-13 Responsive Coach design: Single Coach for multiple form factors
180 Business Process Management Design Guide: Using IBM Business Process Manager
To manage the data flow of objects that are required inside the process, two
major approaches are used. Call by reference and call by value:
Call by reference
With call by reference, the object model on the process layer contains only
the bare minimum information, which is required for the following items:
SOR IDs
Naming process and task instances
Routing tasks
Searching process and task instances
Tracking process information
The SOR IDs are passed into the services (human or system) so that they
can retrieve the complete information by themselves from an external
data source.
The advantage of this approach is that it is the most lightweight approach.
The disadvantage is that every service has to perform resource-intensive
integrations to retrieve and save data.
Call by value
With call by value, the object model on the process layer contains the sum of
all information that is necessary to perform the tasks. The process passes all
required information to the task, and the task returns all changed information.
This data handling approach uses the most resources.
The advantage of this approach is that it can theoretically exist without an
SOR. However, it is advised to create an SOR for auditing, reporting, and
other reasons. The disadvantages are that this is the most expensive
approach because large data objects are persisted in the runtime
environment and database, and therefore this approach uses the largest
amount of resources.
Important information about how to handle data on Coach Views can be found in
the following sources:
Coach View design on page 176
IBM Business Process Manager V8.5 Performance Tuning and Best
Practices, SG24-8216
Leveraging the IBM BPM Coach Framework in Your Organization,
SG24-8210
182 Business Process Management Design Guide: Using IBM Business Process Manager
5.4.4 Integration design
In this section, we describe the following topics:
Service orchestration and choreography implementation types
Difference between mediation flow component and short-running BPEL
When IBM BPM Advanced Integration Service should be used
Transactionality
For more information about these solutions styles, see the following IBM
developerWorks article:
http://www.ibm.com/developerworks/websphere/library/techarticles/1004_c
lark/1004_clark.html
The mediation flows can be used to start the back-end systems in which
business context does not change.
184 Business Process Management Design Guide: Using IBM Business Process Manager
Short-running BPEL flow
The short-running BPEL, also called a microflow, is a synchronous or stateless
service that is used when the corresponding business transaction is fully
automated and completes within a short time frame. Microflows run in a single
physical transaction, and they are non-interruptible.
Microflows can include the integration logic that entails the invocation of one or
more mediation flow components. They provide a complex choreography of
sequences of requests to mature exposed services in a single transaction. In
IBM BPM, looping constructs, such as foreach, while, and repeat until, are
much easier to implement in a microflow than in a mediation flow component.
The choice between the mediation flow component and the microflow is driven by
the pattern that you want to implement. For example, consider using the
mediation flow component for service virtualization and brokerage patterns.
Nevertheless, microflow would be appropriate for implementing composition
patterns, such as state-free orchestration. We suggest that you refrain from
implementing business logic in a mediation flow component.
When IBM BPM Advanced Integration Service should be used
In IBM BPM, IBM BPM Advanced Integration Service (AIS) is used to implement
business services that are to be used by a business process. Business services
are steps in a business process that are not apparent to the business users.
These are steps that business users are typically not interested in monitoring. In
other words, a business service is a low-level technical implementation that
updates the business context but is not of much interest to the business users.
AIS can be a good match in a scenario that involves STP of business steps that
are triggered by a business user. In this situation, the human interaction required
to start the business steps is implemented by the process developer in IBM
Process Designer.
Transactionality
In this section, we describe the following aspects of transactionality:
Transaction types in IBM BPM
Synchronous versus asynchronous transactions
186 Business Process Management Design Guide: Using IBM Business Process Manager
Synchronous versus asynchronous transactions
Services provided over a controlled local infrastructure can make design
assumptions that enable true transactionality, and therefore synchronous
interaction patterns can be used in such situations. As a result of the unreliable
medium between consumer and provider, enterprise services can only provide
true reliability when using an asynchronous pattern of behavior. Truly
asynchronous interaction provides the following benefits:
Requesting thread is not blocked.
System non-availability problems associated with a provider are naturally
handled with the implicit store and forward pattern, therefore removing the
need for more coding.
In summary, if you need assured delivery and idempotence, your error handling
pattern is typically asynchronous.
Toolkits, per design, are meant for reuse purposes. The most common
challenges during the initial process application design are classification and
grouping library items into respective toolkits. In addition to those challenges,
ongoing maintenance of toolkit artifacts during active development processes
can also be a demanding exercise.
188 Business Process Management Design Guide: Using IBM Business Process Manager
Analyzing the following areas can help to outline a list of potential toolkits:
Business objects libraries
It is not uncommon for the business objects toolkit to include integration
services that use those objects definitions. This approach can provide a
certain degree of encapsulation for integration services and their respective
business objects.
Integration-specific related toolkits
Bringing together integration services related to persisting data in the existing
repository that includes several existing software solutions can be an example
of an integration-specific toolkit. It might not make much sense to create
individual toolkits for each existing system, but rather to place all existing
system-related integrations into a single toolkit.
Such an approach will keep all existing related integrations in a single library,
enabling easy disassociation of the existing integration services from the next
generation of services when the former are fully decommissioned.
System-specific or business purpose-specific
For example, an IBM FileNet toolkit can include client-owned FileNet related
integration services. In addition, business objects supporting the IBM FileNet-
specific operations can also be defined in this toolkit. This classification might
work better if there are fewer integration systems that the IBM BPM solution
needs to interact with. A client solution with a larger number of integrations
might, otherwise, have to deal with many dependant toolkits.
User interface library items
This is a good way to share reusable UI-related items, such as common
libraries of JavaScipt code, CSS style sheets, or Coach Views, across
multiple process applications.
Third-party libraries
Keeping a toolkits size to a minimum is a worthy goal. When using third-party
toolkits, there are not that many options to achieve such a goal. There is
generally no documentation that comes with the toolkit that describes the
toolkits internal dependencies. Refactoring a third-party toolkits code, in an
attempt to break it down into smaller libraries, can prove costly and often yield
no guarantee that the final result is as stable as the original toolkit version.
In cases when you strongly want to reduce the size of the toolkit, one safe
option that can be used is to contact the toolkit vendor with a request to
refactor the toolkit code. There is a good chance that the toolkit vendor will
cooperate and offer an acceptable alternative toolkit implementation. After all,
it is in the toolkit vendors best interest to keep their clients happy.
For more information about toolkit dependencies and archiving, see the IBM
Knowledge Center that describes deleting toolkits:
http://www.ibm.com/support/knowledgecenter/SSFPJS_8.5.5/com.ibm.wbpm.ad
min.doc/topics/tadm_delete_toolkits.html?cp=SSFPJS_8.5.5&lang=en
If the number of library items that are actually being used grows to the point
where they affect deployment timing, you can revisit the initial toolkit
categorization choice that was originally made at the beginning of the project.
Before proceeding with the refactoring exercise, we advise you to assess and
analyze the overall effort to be spent on refactoring and testing against the
potential benefits of the refactoring. We also advise you to thoroughly analyze
toolkit dependencies and hierarchy at the initial design phase of the project, to
avoid potentially troublesome refactoring activities.
190 Business Process Management Design Guide: Using IBM Business Process Manager
When designing toolkits for integration services using IBM BPM AIS artifacts, we
advise you to use a facade pattern. This is a good pattern, because it avoids
excessive or accidental breakages by shielding the data types and the interfaces,
and isolating the models from changes introduced through other tools.
http://www.ibm.com/developerworks/websphere/bpmjournal/1112_pacholski/1
112_pacholski.html
For more general information about the facade pattern definition, see Martin
Fowlerss site:
http://martinfowler.com/eaaCatalog/remoteFacade.html
Toolkits are reused by process applications and other toolkits by copy. To take
advantage of new changes made in a toolkit, you need to create and deploy a
new snapshot of the toolkit where the change was made.
In addition to cleaning the runtime environment from the unused snapshots, the
potential negative effect can be mitigated by using the Service facade pattern.
Next, we look at the main benefits of applying the Service facade pattern during
integrations development:
To limit an excessive number of runtime artifacts deployed onto the
Process Center
To promote isolation of private service interfaces defined in IBM AIS
To promote and support loose coupling between business objects definitions
made in the IBM Process Designer and IBM Integration Designer
environments
For more information about business object model design considerations, see
3.3.3, IBM BPM business object model design considerations on page 92.
192 Business Process Management Design Guide: Using IBM Business Process Manager
When applying the Service facade pattern to the IBM AIS implementation, it is
important to consider the different types of facade implementations, and
recognize their strengths and limitations:
Managed implementation option
For the facade pattern implementation with IBM AIS, you can consider placing
the AIS implementation in the process application to reduce multiple
implementation copies of it. This approach is often referred to as managed
implementation, because all related facade interfaces and their
implementation are managed in the Process Center.
Note that you still get multiple copies of the facade toolkit every time it is being
referenced. On the positive side, it is a relatively thin deployment asset,
because the facade contains interface definitions only.
On the negative side, the code is deployed in three locations:
The facade interface definition in the toolkit
The process application with the facade implementation
The corresponding service code in IBM Integration Designer
All of these copies need to be in sync. In some cases of frequently changing
integration services during development, keeping these three parts in sync
can become an additional maintenance challenge.
Unmanaged implementation option
In this facade version, services are implemented as SCA assets on the IBM
Integration Designer side. The difference between the managed and
unmanaged options is that there is no process application asset that is
managed by the Process Center. Service implementation code is relatively
decoupled from its interface definition, which is part of the facade toolkit.
Unmanaged implementation with dynamic end-point location
When end-point location is unknown or inaccessible at design time, it is
worth considering a dynamic endpoint selection (DES) pattern inside the
facade implementation.
For more information about the DES pattern, see the IBM Knowledge Center
about creating DES patterns:
http://www.ibm.com/support/knowledgecenter/SSFPJS_8.5.5/com.ibm.wbpm
.auth.stp.doc/services/topics/creatingdespattern.html?lang=en
For more information about the rule-based DES pattern implementation, see
the following IBM Knowledge Center:
http://www.ibm.com/support/knowledgecenter/SSFPJS_8.5.5/com.ibm.wbpm
.auth.stp.doc/services/topics/rules_based_des_pattern.html?lang=en
194 Business Process Management Design Guide: Using IBM Business Process Manager
5.6 Error handling
The subject of error handling comes up on every IBM BPM engagement, and
should be considered one of the key areas to be carefully designed and
implemented. In this section, we describe the main error handling concepts, and
cover strategies that can be applied in real life solution implementations:
Error handling concepts
Error handling strategies
Next, we take a look at examples of different error types, and how they can
be categorized.
These errors are business meaningful and are known at design time, so there is
an option to handle them programmatically, or as part of the surrounding
business process. Hoverer, if such errors occurred at run time, they are typically
permanent in nature.
196 Business Process Management Design Guide: Using IBM Business Process Manager
Application exception bugs
Exception bugs are errors within application code that result in unplanned
exceptions. Poor handing of non-populated data and incorrect creation or parsing
of data formats are examples of such errors. These types of errors are typically
permanent for a specific set of application data. They can only be resolved
through a code change and new release of the application.
Product bugs
These errors occur when the underlying product does not behave as
documented. They can only be resolved through a new release or fix pack of
product code, or by coding a workaround in application code. Such errors are
typically permanent, although more rarely they can be intermittent.
Analyzing different types of errors helps you classify them into logical categories
that further help you to understand what the clients expectations for error
handling are.
198 Business Process Management Design Guide: Using IBM Business Process Manager
Where the errors will show up
Now that we described the types of errors, we look at some of the concepts
related to the mechanics of error origins:
Request-response, blocking transport
A two-way call with an SLA suited to online users (so the task completes in
seconds rather than minutes). All errors are passed back to the caller:
Caller can be confident of the end state if a transactional protocol is used.
Needs to be transactional for updates.
The consumer can initiate a transaction, and the provider can participate.
If the communication medium is unreliable, or the consumer is not
transactional, there is a possibility for data loss or duplication. In this
situation, we lose the benefits of transactionality, because we must
implement asynchronous error handling anyway.
Request-response, non-blocking transport, real time
A call that involves asynchronous transport, but with an SLA equivalent to
synchronous invocation:
Most errors are passed back to the caller. If the call succeeds, the caller
can be confident of the end state. If the call fails, especially for timeout, the
end state can be in doubt. Even brief system outages can result in an
in-doubt state.
Because this is not a single transaction, there is an opportunity for the
caller to be left in an in-doubt state. You must therefore implement an
asynchronous error handling pattern to manage the in-doubt state.
Request-response, non-blocking transport, non-real-time
A call made over an asynchronous medium whose response is not
guaranteed in a time frame appropriate for real-time consumers:
Caller can be confident of the delivery of the request. On receipt of a
response, success is assured. Any time in-between, the state is unknown.
On timeout, the end state is unknown. Transient errors should be rare,
because there is time for tries to be made again.
The in-doubt state should be treated as an expected in-progress state,
and the surrounding systems should be able to query for, and act upon,
that state. All error handling is fundamentally asynchronous.
Fire and forget, non-blocking transport
A call made over an asynchronous medium that requires no response:
Caller can be confident of delivery of the request.
In theory, no error handling is required, but you might need more analysis
of requirements and circumstances to make the final judgment about
whether a response is not truly necessary.
A real error handling strategy requires more effort to analyze the clients
requirements and overall solution landscape in order to produce the detailed
content for the first two items in the previous list. On a project, more than one
error handling strategy might be required. For example, it is common to have a
different strategy for asynchronous and synchronous interactions, and a specific
approach defined for presenting different types of errors on a UI.
The following list describes general guidelines for error handling strategies:
Where concurrent access to data is probable, all users of the data must be
taken into account when considering the locking strategy.
Solutions should only leave behind failed events that represent a problem to
be resolved. Errors that are automatically resolved should be cleaned up. It is
also acceptable that they leave an audit trail or log.
Example error handling strategies can be divided into the following categories:
Strategy for STP
The strategy assumes no long-lived processes or human tasks on the happy
path (the ideal version of the process). Rather, consider chained mediations
or asynchronously started, briefly persisted processes.
Error handling would occur offline from the main path in a separate
component to the main processing. This might contain long-lived
components.
200 Business Process Management Design Guide: Using IBM Business Process Manager
Strategy for generic offline error handling
Errors are outsourced to a generic component that enables processes to
complete rather than clog up the system. Error handling can be progressively
automated, rather than having to be built into all of the processes from
the beginning.
A good implementation example of this strategy in IBM BPM, applicable for
both BPMN process and SLA exception handling, is the General Exception
Handler toolkit. It is a community-based asset available on the IBM BPM
Community Wiki site:
http://wiki.bpmwiki.com/display/samples/GEX+Toolkit+%28General+Excep
tion+Handler%29
Strategy for failure point resubmission
This strategy is predominantly relevant to long-running and asynchronous
scenarios. All errors are resolved at their failure point, and resubmitted if
possible. It works well for ensuring that processes continue to completion
wherever possible. All points where errors can occur are provided with a
mechanism to store the current error state in a resubmittable form.
Progressive error handling strategies
It is not uncommon when a client, due to various reasons, has no input about
how their want errors to be handled in the process application. For example,
the client can have security-based constraints to provide access to the
server-side resources. In such cases, an approach that makes much sense is
to follow a progressive error handling strategy.
You start from the basic approach, which is assuming that all errors are
returned to a caller, whether it is a user or a calling system. As the project
progresses, more information gets collected, knowledge about the process
evolves, and the error handling approach evolves along with it.
The following list provides a summary of progressive error handling strategies
for synchronous transactions:
Basic All Errors are passed back to the caller.
Automated Permanent errors are passed back to the caller.
For transient errors, perform additional tries according
to static policy, then behave as for permanent errors.
For business errors, handle according to agreed on
static business rules. In case of non-conforming logic,
respond as for permanent errors.
202 Business Process Management Design Guide: Using IBM Business Process Manager
5.7 Logging
As one of the aspects of runtime system visibility, logging should be considered
an important part of every IBM BPM solution. The overall solution visibility aspect
is covered in more detail in Chapter 6, Business-centric visibility on page 217,
and Chapter 7, Performance and IT-centric visibility on page 231 of this book.
There are several options that can be used for logging purposes in the IBM BPM
process application, including the ones that come with the product.
The following sections describe options that you can consider for various types of
logging within IBM BPM.
The appropriate logging level can be set in the WebSphere Application Server
Administrative Console, as described in the following IBM Knowledge Center:
http://www.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphe
re.nd.doc/ae/ttrb_configjavalog.html?lang=en
http://www.ibm.com/developerworks/websphere/techjournal/0901_supauth/09
01_supauth.html#icomments
http://wiki.bpmwiki.com/display/commwiki/Custom+logging+using+Log4j+in+
IBM+BPM+7.5.x+and+8
204 Business Process Management Design Guide: Using IBM Business Process Manager
5.8 Asset maintenance and governance considerations
Considering the fact that the vast majority of the lifetime of process assets lies in
a post-development phase, asset maintenance becomes an increasingly
important aspect of the process lifecycle. Governance around deployment and
source code maintenance are other integral parts of the overall solution that
require careful consideration and planning.
Starting with the version 8.0 release, IBM BPM enables you to federate remote
process centers through the Process Center self-registering mechanism. When
you register two Process Centers with each other, you can share toolkits with
other users, or subscribe to toolkits that other users share.
You can share toolkits with other users, even if those users are working in a
different Process Center. You no longer need to first export the toolkits from one
Process Center and then import them into another Process Center.
After a toolkit is shared, events are synchronized, and snapshots are released
automatically once every 24 hours. The sharing Process Center is notified when
a shared toolkit is being used on a registered Process Center. The subscribing
Process Center is notified of new released snapshots and of the state of the
shared toolkits.
http://www.ibm.com/support/knowledgecenter/SSFPJS_8.5.5/com.ibm.wbpm.ad
min.doc/topics/sharing_pa_toolkit.html?lang=en
Table 5-3 describes the specific rules that you must consider when you
share toolkits.
Sharing a toolkit when the The toolkit does not have child dependencies.
snapshot status is set to The toolkit has dependencies, but all snapshots that are used
Released from children are set to Released.
For more information about rules for sharing toolkits, see the following IBM
Knowledge Center:
http://www.ibm.com/support/knowledgecenter/SSFPJS_8.5.5/com.ibm.wbpm.ad
min.doc/topics/rrules_tk.html?lang=en
206 Business Process Management Design Guide: Using IBM Business Process Manager
Figure 5-18 provides an example of a distributed development environment
across multiple geographically dispersed Process Centers.
The functionality should be ready for integration testing with the rest of the parts
of an overall process solution. This approach further encourages component
design and code reuse, following leading practices in software design.
For more information about toolkit design considerations, see 5.5, Toolkit
design on page 188.
When working with process applications or toolkits, you might need to provide a
link to related information that is available outside of the IBM BPM environment.
For example, you might want to link to a website or a wiki page. You can also
reference a change request stored in a change management system, or a test
case in a quality management system.
For more information about using remote assets in IBM Process Designer, see
the following IBM Knowledge Center:
http://www.ibm.com/support/knowledgecenter/SSFPJS_8.5.5/com.ibm.wbpm.ad
min.doc/topics/cusing_remoteassets.html?lang=en
All development artifacts created in IBM Process Designer get managed by the
Process Center, and get implicitly persisted in the Process Center repository. No
external source control tool is necessary for assets created in IBM Process
Designer. No additional effort for persisting and managing process applications
and toolkits is required, because the Process Center does it for you transparently.
Multiple users can simultaneously access and change process applications and
library items in IBM Process Designer. When you edit concurrently, you
collaborate with other team members to create the library items that you need for
your project. For example, you can communicate about your ideas and edits
using instant messaging, and see the results in the Designer view as
they happen.
When multiple users work on the same library item, such as a human service,
each user can see the changes when edits are saved. To ensure that all users
are aware of which library items are open and what changes are being made,
IBM Process Designer provides the following notifications:
Notifies you when another user opens a library item, by showing a user icon.
You can hover over the icon to see who that user is.
Notifies you when another user is editing a library item, by displaying the
words Read Only next to the library item. When users save their work, the
library item is available to edit.
208 Business Process Management Design Guide: Using IBM Business Process Manager
Notifies you when another user has saved changes while you are editing a
library item, by displaying the words Read Only next to the library item. When
you click Save, a Save conflict message displays. You are prompted either to
save your changes and override the other users changes, or discard the
changes and accept the other users changes.
Notifies you when multiple users start to edit a library item at the same time,
before the Read Only text appears, by displaying a warning icon and
message. The message prompts each user to either immediately save their
changes or discard them.
You can enable IBM Process Designer users to share library items across
process applications. Process applications can share library items from one or
more toolkits, and toolkits can share library items from other toolkits.
Users who have access to a toolkit can create a dependency on the toolkit, and
use the library items within it for their process development efforts. See 5.8.1,
Shared assets in IBM BPM Process Center on page 205 for more information
about sharing library items across Process Centers.
http://www.ibm.com/support/knowledgecenter/SSFPJS_8.5.5/com.ibm.wbpm.ad
min.doc/topics/managinglib_introduction.html?lang=en
The IBM Process Designer view offers several tools to ensure that you can
access items that you work with regularly. With IBM Process Designer, you can
move or copy items between existing or new process applications and toolkits.
You can also revert to previous versions of individual library items using
snapshots.
We advise you to organize the development artifacts in smart folders, and take
advantage of tagging capabilities in IBM Process Designer. As practice shows,
using these organizational features of IBM Process Designer increases the
productivity of development teams, and improves code maintenance.
Improvement in code maintenance is especially visible, and material for the
long-term projects with periodic team member rotations.
For more information about managing library items in IBM Process Designer, see
the following IBM Knowledge Center:
http://www.ibm.com/support/knowledgecenter/SSFPJS_8.5.5/com.ibm.wbpm.ad
min.doc/topics/managing_lib_items.html?lang=en
210 Business Process Management Design Guide: Using IBM Business Process Manager
These artifacts can be deployed to the IBM Process Server with the process
application. An example of such an artifact is an AIS implemented in IBM
Integration Designer and published in the Process Center for consumption by
activities defined in the business process diagram. For details about how to
synchronize IBM Integration Designer with the Process Center, see the
following IBM Knowledge Center:
http://www.ibm.com/support/knowledgecenter/SSFTDH_8.5.5/com.ibm.wbpm
.auth.stp.doc/processcenter/topics/cprocesscenter.html
Refrain from publishing these artifacts to the Process Center. In such
situations, the modules and libraries implemented in IBM Integration
Designer can be managed using an external source control system, and
deployed directly to the IBM Process Server. For more information about
deploying assets to the IBM Process Server, see the following IBM
developerWorks article:
http://www.ibm.com/developerworks/bpm/bpmjournal/1212_iyengar/1212_i
yengar.html
Figure 5-20 illustrates the Process Center with a process application that has the
status of Waiting for approval. When approved, a snapshot is installed.
The governance process will be executed whether you deploy online from a
connected process center environment or chose to have an offline deployment.
Remember: The governance process works for both online and offline
deployment models.
212 Business Process Management Design Guide: Using IBM Business Process Manager
In addition to this, there can be many non-main tracks. All tracks (default and
non-default) run under the umbrella of the process application. Therefore, they
are not true duplicates.
When a track is the default track, the library items within it run by default when an
event or other trigger that applies to items in more than one track is received by
the Process Center server. For example, when you are executing a service using
a URL, and that service exists in more than one track, the service in the default
track is run.
If you create a snapshot that is being used for testing or demonstrations, you
usually dont want to use tracks to manage this snapshot. The value of tracks can
be reduced by the resources required to manage them and their functionality,
and to ensure that changes are properly propagated among all necessary tracks
and environments. Try to keep the number of tracks as low as possible. The most
common usage for tracks is to support a production release.
V1.0 marks the snapshot that will be deployed into production. At this point, it
makes sense to create a track for this. In Figure 5-21, this track is called
Production Support Track.
As the Production Support Track goes into production, on the Main Track the
development continues as normal, and further versions or releases (V2.0) are
being created.
Generally, the release cycles should be short enough that required changes or
fixes can be deployed directly from the main track into production (of course,
while respecting all required quality assurance phases). However, on occasion,
there might be a requirement for an interim fix to the production environment.
An interim fix is a high-effect fix that is required to keep the currently deployed
version usable. This fix can be created in the Production Support Track, because
no other changes, such as the ones that might already be part of the continuous
development track, must be deployed yet. After the fix is created, it has to be
merged into the main track. IBM BPM provides a set of capabilities to support
this, which leaves us with two approaches for merging, automated and manual:
Automated
The IBM BPM process center provides the ability to compare tracks, visualize
the changes, and merge changes between track versions.
214 Business Process Management Design Guide: Using IBM Business Process Manager
Figure 5-22 shows the Process Center view that highlights whether there
were conflicts or new items.
On the upper left corner, Process Center provides you the option to filter by
All, New, Updated, and Conflict. The list of items is highlighted as such. In
Figure 5-22, you see the orange highlighting of updates. If you open the list
item, you see a visual representation of the changes. In this case, an activity
has been deleted (on the diagram on the left side).
Now you can decide whether you want to copy this change. On the upper right
corner, there is a button that you can click to proceed with this operation.
5.9 Conclusion
In this chapter, we described the difference between processes and services,
and what to remember when creating either of them. We talked about routing
patterns and the difference between pushing and pulling tasks for user execution.
216 Business Process Management Design Guide: Using IBM Business Process Manager
6
218 Business Process Management Design Guide: Using IBM Business Process Manager
Process analysts can use the process data, such as KPIs and SLAs, to
make improvements to a business process to meet and exceed the
process performance targets. They can use this process performance
information to make tangible process improvements to the process. It is
important to state that the process analysts must not make any process
improvements without first consulting with the process owner.
For more information about how to collect and use process performance data,
see the IBM BPM 8.5.5 Knowledge Center on the following website:
http://www.ibm.com/support/knowledgecenter/SSFPJS_8.5.5/com.ibm.wbpm.wl
e.editor.doc/topics/tpd_designtracking.html
1 An initial effort must be carried out to identify the process data that must be tracked, and to ensure
that the tracked data offers business value.
2
It is important to note that the use of IBM Business Monitor can require additional licenses.
220 Business Process Management Design Guide: Using IBM Business Process Manager
These reports in IBM BPM can be used to get a high-level overview of the
business process, including but not limited to the following information:
Process performance
Team performance
Task status
The following subsections describe the steps to create reports from external and
internal data sources:
High-level steps to create custom reports that display data retrieved from
external data sources in IBM BPM. We also describe important points to
consider before implementing these reports in IBM BPM.
High-level steps to create custom reports that display data retrieved from data
sources that are internal to IBM BPM. We also describe important points to
consider if you have a requirement to retain large volumes of process data in
the Performance Data Warehouse database.
Consider implementing such reports in IBM BPM when they meet the
following criteria:
They present vital application data information that is critical to making quick
and informed decisions in a business process task.
They require joining of the business data and the inflight process data
retained in the Process Server database.
These custom reports involve presenting the application data, retained in an
external SOR, to the process owners and the process participants in the IBM
Process Portal. Before developing these custom reports, it is important to
analyze the external SOR to understand how the information is stored, and how it
is retrieved and presented to the process owners and the process participants.
222 Business Process Management Design Guide: Using IBM Business Process Manager
4. At run time, when these reports are started by the business users or the
process participants in the IBM Process Portal, the application data required
for these reports is retrieved from the external SOR using the integration
services. This data can also be combined with the inflight data (retained in the
Process Server database) retrieved using application programming interfaces
(APIs) defined in IBM BPM.
5. Present the data retrieved in the previous step (step 4) in the UIs displayed in
IBM Process Portal.
Consider the following points if you need to retain large volumes of process data:
Manually archive the process data from the Performance Data Warehouse
database to an external database3 regularly. The frequency of the process
data archives is typically driven by your business requirements. This
approach provides the following advantages:
Requests to retrieve the historical process data can be offloaded to an
external data store, as shown in Figure 6-3 on page 225.
Reports to display the historical process data from an external data source
can be hosted outside IBM BPM.
3
Approach can typically involve additional license, design, implementation, and operational costs.
224 Business Process Management Design Guide: Using IBM Business Process Manager
Define a purging strategy for the Performance Data Warehouse database.
Regularly purging the process data can lead to better response time on
process data retrieval requests made to the Performance Data Warehouse
database. For information about purging data in Performance Data
Warehouse database, see the following IBM developerWorks article:
http://www.ibm.com/developerworks/bpm/bpmjournal/1312_spriet/1312_sp
riet.html
Figure 6-3 Custom reports using process data archived to an external data source
They need the ability to perform path and segment analyses of their processes,
and then optimize accordingly. To accomplish this, they need to be able to bring
rich performance and business data (beyond just, for example, average task
duration) into the context of their business process model.
Bringing this data into context is what IBM BPM Process Optimizer is designed to
do. IBM BPM Process Optimizer helps the business analysts to improve
processes by showing where and how to change the process model. The IBM
BPM Process Optimizer enables the business analysts to perform a wide range
of analysis and optimization scenarios.
These scenarios range from simple simulations to validate the overall process
modeling strategy, to advanced what-if comparative analyses using historical,
inflight, or simulated data (or any combination of the three). IBM BPM Process
Optimizer also gives the business analysts the ability to analyze KPIs and SLAs
tracked and stored from a process instance at run time.
In the following sections, we describe some examples of how the IBM BPM
Process Optimizer can be used to drive valuable process and business insight:
Simulation of a business process
Optimization analysis using historical performance data
Optimization analysis using inflight performance data
Guided optimization
226 Business Process Management Design Guide: Using IBM Business Process Manager
Optimization analysis using historical performance data
Simulation is a powerful mechanism to identify potential bottlenecks and potential
cost reductions, to cost-justify resource allocations based on expected volumes,
and to optimize process designs. However, the fundamental flaw in any process
simulation of meaningful complexity is that all of the properties that need to be
completed are often based on assumptions rather than real-world data.
The outcome is a simulation model and results that are themselves only best
guesses at possible performance. IBM BPM provides closed-loop simulation that
can automatically populate the property sheets with real-world performance data
on the existing process from the Performance Data Warehouse, making the
simulation accurate and meaningful.
It is important to ensure that the data collected for such simulations is proper in
order to make the simulation accurate and meaningful. For example, you are
considering the addition of an approval step that is conditional based on the type
of account. How would the addition of that step affect the process based on past
history? With IBM BPM, all of the simulation parameters from existing steps can
be automatically populated by historical data from any period of time you choose.
How often and in what specific cases is this conditional step taken? To answer
this question, you must be able to run historical process data through your
proposed process changes. IBM BPM enables you to do exactly this.
Furthermore, you can create scenarios that filter the analysis based on specific
business data.
In the same way that you want realistic parameters for simulation based on
historical data, you also want to know how these changes are going to affect your
current inflight processes. The IBM BPM Process Optimizer can run the same
type of performance analysis using the business and process data of inflight
tasks, such as the current numbers of active tasks, overdue tasks, and the
metadata associated with each instance.
The IBM BPM Process Optimizer can tell you what is going to happen in the
future using current data. In addition, with heat map animation and a time scale
as a slider, IBM BPM can tell you where a bottleneck will occur in the future, and
when it will occur as well. For the real-time enterprise reacting to business
events, such an analysis is essential.
Therefore, the IBM BPM Process Optimizer not only tells you what will happen if
you make a change, but can also suggest what changes to make based on the
same real-world data.
For more information about simulating and optimizing business processes using
IBM BPM Process Optimizer, see the IBM BPM 8.5.5. Knowledge Center:
http://www.ibm.com/support/knowledgecenter/SSFPJS_8.5.5/com.ibm.wbpm.wl
e.admin.doc/topics/optimizer_introduction.html?lang=en
IBM Business Monitor can also help make an organization aware of potential
problems proactively, enabling a directed action to be planned and carried out.
Organizations are empowered with the capability of taking the correct action at
the correct time, helping to realize more value from IT. IBM Business Monitor is
relevant in all areas of the business, across both the functional and process
perspectives.
A financial institution, for example, might use it to manage and track loan
processes in real-time, combining information about human and automated
elements of the process into a single view.
A government could use IBM Business Monitor to gain visibility into operations of
the social services agency department.
228 Business Process Management Design Guide: Using IBM Business Process Manager
In health care, IBM Business Monitor can be used to have an overview of all
operations within a hospital, including management of insurance claims
processing, scheduling of testing equipment needs and staff assignments.
For more information about IBM Business Monitor, see the IBM Business Monitor
8.5.5 Knowledge Center:
http://www.ibm.com/support/knowledgecenter/SS7NQD_8.5.5/com.ibm.wbpm.mo
n.doc/kc-home.html
230 Business Process Management Design Guide: Using IBM Business Process Manager
7
The following section provides details about the steps shown in Figure 7-1:
1. Start with initial IBM BPM system settings based on best practices outlined in
the IBM Redbooks publication IBM Business Process Manager V8.5
Performance Tuning and Best Practices, SG24-8216.
2. Initiate a performance test with the intended target load to determine if the
current configuration can meet the performance target, including the
throughput and response time target. If the target can be met, no further
performance tuning is required.
232 Business Process Management Design Guide: Using IBM Business Process Manager
3. If the IBM BPM system cannot handle the intended target load, verify the
current system topology with a suggested configuration based on estimated
sizing values1.
4. If the current environment settings are lower than the configuration settings
suggested in the sizing exercise, the current topology should be remediated
to increase the system capacity.
5. If the current environment settings match the configuration settings suggested
in the sizing exercise, the saturation point test should be conducted to
evaluate the current capacity. The load that drives the system to its saturation
point can be used as the baseline load (also called the saturation load) for
performance tuning.
6. Monitor the system under the baseline load using performance diagnostic
tools described in 7.3, Performance diagnostic tools on page 238. We
suggest that you start monitoring the system using the following tools:
Nmon analyzer
IBM WebSphere Performance Tuning Toolkit
IBM Monitoring and Diagnostic Tools for Java - Health Center
7. Analyze the performance data captured using the monitoring tools described
in step 6 previously.
8. Tune the system parameters as necessary. We suggest tuning one parameter
at a time before rerunning the performance test to analyze the effect of
parameter change on the performance of the system. It is important to note
that tuning can involve updating the components that are outside the servers
hosting IBM BPM. When tuning such components, we suggest that you follow
the appropriate tuning guidelines.
9. Rerun the performance test under baseline load, and monitor the system
using performance diagnostic tools described in 7.3, Performance diagnostic
tools on page 238. If the IBM BPM system does not meet the performance
target, repeat steps 7 - 9 until the system performance aligns with the
performance target at baseline load.
10.If the system performance meets the performance target at baseline load,
increase the load and rerun the performance test again. If the system
performance does not meet the performance target at increased load, repeat
steps 7-10 until the system performance meets the performance target at
expected production load.
1
We assume that sizing estimates are based on expected production load. As future projects are
added, we suggest re-evaluating the sizing estimates as part of capacity planning exercise.
7.2.1 Logging
Logging involves recording the behavior of a running program for debugging,
monitoring, and troubleshooting purposes. For example, when troubleshooting
problems, logged messages can be used to isolate and make problem
determination local. Logged data can also be used by monitoring tools to analyze
the health of an application, and generate alerts when predetermined error
situations or resource usage limits are encountered.
234 Business Process Management Design Guide: Using IBM Business Process Manager
Apache Log4j2 (Log4j) logging framework. Organizations typically choose to
use Log4j when they are looking for a highly configurable logging utility with
the ability to change configuration values with external files at run time. For
information about using Log4j to create a logging framework in IBM BPM, see
the following IBM developerWorks article:
http://www.ibm.com/developerworks/bpm/library/techarticles/1410_chan
dran/1410_chandran.html
The following list includes typical performance considerations when using
Log4j in an IBM BPM application include the following:
The amount of data being logged at each Log4j log level. For example, the
decision to log an entire message payload or a business object should be
made only after much deliberation, because logging excessive data can
lead to performance degradation.
Enabling logging at the entry point, the exit point, and the exception trace
on application services, as a starting point. More logging points are
typically required during the development phase, but these should be
removed before production release. Therefore, you only take forward
those logging points that are necessary.
Using Log4j asynchronous loggers, where possible. These asynchronous
loggers can offer lower logging latency and higher throughput as
compared to synchronous loggers. For more information about
asynchronous loggers and considerations for choosing between
synchronous and asynchronous loggers, see the following website:
http://logging.apache.org/log4j/2.0/manual/async.html
Guarding Log4j object creation and log message parsing at run time by
first checking for the logging level enabled in Log4j configuration settings.
Ensure that complex strings are not prepared until the logging level has
been checked. This can help reduce the resource use associated with
creating objects and building strings that will not be logged.
Using common code when implementing common logging logic.
Sensible use of Log4j trace levels for logging information. For example,
information that can prove useful at DEBUG trace level must not be logged
under INFO, WARN, or ERROR trace levels.
For more information about application logging in IBM BPM, see 5.7, Logging
on page 203.
2
For more information about Apache Log4j, visit their website at
http://logging.apache.org/log4j/2.x/
7.2.2 Auditing
IT-centric auditing is the practice of recording user actions or a certain type of
transactions, performed in context of a software system or service, for purposes
of compliance. Reliable audit trails can help answer the following questions in
context of user actions performed in an application, or when starting a service:
What was changed in a system or by a service?
Who made the change in a system, or who started the service that triggered
the change?
When were the changes made in a system or by a service?
Was the change performed in the realm of authorization granted to the user?
The amount of data captured for an audit trail and the retention period for an
audit trail is typically dictated by the compliance department in an organization.
For example, financial institutions typically enforce strict requirements for
establishing an audit trail in their software systems and services.
In IBM BPM, an audit trail can be captured for applications and services using
the following tools:
IBM WebSphere Application Server system log files.
Message logger primitive (in IBM BPM Advanced) to store audit messages in
a relational database.
Log4j logging framework. Performance considerations shared in 7.2.1,
Logging on page 234 apply when audit information is captured using Log4j.
236 Business Process Management Design Guide: Using IBM Business Process Manager
7.2.3 Monitoring
IT-centric monitoring is the real-time scrutiny of systems, applications, or services
to proactively identify potential failures, or to detect problems as soon as they
manifest. Monitoring is essential to ensure that the systems, applications, or
services meet their stated goal within the organization. Different categories of
monitoring that must be considered when implementing IBM BPM include:
System health monitoring
System health monitoring encompasses monitoring the health of the physical
and operational systems. It typically includes monitoring the connection pools,
thread pools, queue sizes, memory, processor, network traffic, and disk and
file input/output (I/O). System health monitoring can also include monitoring
the runtime dependencies of supporting subsystem resources, such as file
systems, databases, messaging systems, and a security registry, such as the
Lightweight Directory Access Protocol (LDAP).
Application health monitoring
Application health monitoring encompasses monitoring the health of
functional components that typically include failed events, running
components, and adapters.
Compliance monitoring
Compliance monitoring encompasses monitoring the audit trail to ensure that
the systems, applications, and services are adhering to regulatory and
corporate policies.
Service-level monitoring
Service-level monitoring encompasses monitoring the service level
agreements of exposed services. It typically includes tracking the service
response times, number of service requests from a consumer, and service
request rate on a per-consumer basis. This information can be used to
improve offered services by ensuring that services meet the response times
agreed on between service consumers and service providers.
It can also be used to throttle requests from a consumer during peak load to
ensure that all consumers get their share of the agreed service by way of SLA
between service consumer and service provider.
Problem diagnostics monitoring
This includes drilling down to the details of issues highlighted in each of the
previous monitoring categories, such as deadlocks, hung threads, memory
leaks, and performance bottlenecks. For more details about problem
diagnostic monitoring in IBM BPM, see the IBM Redbooks publication IBM
Business Process Manager V8.5 Performance Tuning and Best Practices,
SG24-8216.
7.3.1 Nmon3
The nmon tool can be used to monitor system metrics on IBM AIX and
Linux systems:
Processor use
Memory use
Kernel statistics and run queue information
Disk I/O rates, transfers, and read/write ratios
Free space on file systems
Disk adapters
Network I/O rates, transfers, and read/write ratios
3 We suggest that you consider using utilities, such as Task Manager and Perfmon, for monitoring the Windows servers.
If you are hosting IBM BPM on virtual servers, contact your operational team for suggestions about monitoring tools that
can be used to monitor those servers.
238 Business Process Management Design Guide: Using IBM Business Process Manager
Paging space and paging rates
Processor and AIX specification
Top processors
IBM HTTP web cache
User-defined disk groups
Machine details and resources
Asynchronous I/O: AIX only
Workload Manager: AIX only
Network File System (NFS)
Dynamic logical partition (LPAR) changes: Only IBM pSeries (IBM System
p5) and IBM OpenPower for either AIX or Linux
For more information about nmon, see the following IBM developerWorks article:
http://www.ibm.com/developerworks/aix/library/au-analyze_aix/
For information about enabling PMI in IBM BPM, see the IBM BPM 8.5.5
Knowledge Center at:
http://www.ibm.com/support/knowledgecenter/SSFPJS_8.5.5/com.ibm.wbpm.ad
min.doc/topics/tmon_prfstartadmin.html
In addition to capturing the key performance metrics, PTT also shows the
topology retrieved after connecting to the IBM BPM cell, and a list of servers
configured in the IBM BPM cell. For more information about PTT, see the
following IBM developerWorks article:
http://www.ibm.com/developerworks/websphere/downloads/performtuning.htm
l
7.3.3 IBM Monitoring and Diagnostic Tools for Java - Health Center
The IBM Monitoring and Diagnostic Tools for Java - Health Center (IBM Health
Center) provides a no-charge, low-resource diagnostic tool and API for
monitoring an application running on a JVM. IBM Health Center gives the ability
to assess the current status of a running Java application. IBM Health Center
continuous monitoring provides the following information to identify and help
resolve problems with your application:
Identify if JVM native memory or JVM heap memory is leaking. When
memory leaks are identified, they can be investigated further using IBM
Monitoring and Diagnostic Tools for Java - Memory Analyzer to identify the
source of the memory leak.
IBM Health Center can be used with PTT and nmon to identify methods that
lead to high processor usage.
Identify I/O bottlenecks.
Visualize garbage collection statistics. Concerns highlighted in garbage
collection statistics can be investigated further using verbose garbage
collection (verbose GC) traces in WebSphere Application Server. We suggest
using the pattern modeling and analysis tool (PMAT) for IBM Garbage
Collector for analysis of the verbose GC trace files.
View any lock contentions.
Analyze unusual WebSphere real-time events.
Monitor application thread activity.
Detect deadlock conditions in an application.
Gather class histogram data.
240 Business Process Management Design Guide: Using IBM Business Process Manager
In an IBM BPM production environment, we suggest configuring the IBM Health
Center agent in headless mode. In headless mode, the IBM Health Center agent
writes data to the local files on the JVM system, and the resulting .hcd files can
be loaded to the IBM Health Center client on a different system.
This eliminates the need for changes in the firewall rules to establish connectivity
between IBM Health Center client and IBM Health Center agent, assuming that
the client and agent run on different systems.
For more information about IBM Health Center, see the IBM Knowledge Center:
http://www.ibm.com/support/knowledgecenter/SS3KLZ/com.ibm.java.diagnost
ics.healthcenter.doc/homepage/plugin-homepage-hc.html?lang=en
7.3.5 Pattern Modeling and Analysis Tool for IBM Garbage Collector
PMAT analyzes verbose GC traces by parsing the traces and building pattern
models. PMAT suggests key configurations by executing a diagnostic engine and
pattern modeling algorithm. If there are any errors related with Java heap
exhaustion or fragmentation in the verbose GC trace, PMAT can diagnose the
root cause of failures. PMAT provides rich chart features that graphically display
Java heap usage.
For more information about PMAT, see the IBM Support Assistant 5.0 Knowledge
Center on the following website:
http://www.ibm.com/support/knowledgecenter/SSLLVC_5.0.0/com.ibm.trove.t
ool.pmat.doc/docs/readme.html?cp=SSLLVC_5.0.0%2F8&lang=en
242 Business Process Management Design Guide: Using IBM Business Process Manager
Ability to identify deadlocks between threads.
Ability to compare multiple thread dumps (also called Java dumps or Java
core files).
For more information about IBM Thread and Monitor Dump Analyzer, see the
IBM Support Assistant 5.0 Knowledge Center at:
http://www.ibm.com/support/knowledgecenter/SSLLVC_5.0.0/com.ibm.esuppor
t.tool.tmda.doc/docs/readme.htm?cp=SSLLVC_5.0.0%2F9&lang=en
244 Business Process Management Design Guide: Using IBM Business Process Manager
In IBM BPM Advanced, use the WebSphere Application Server PMI tool to
monitor the service integration bus (SIBus) queue depth. Because SIBus
is used by IBM BPM Advanced, it is important to monitor the SIBus
exception queues for error messages. A large accumulation of error
messages on the exception queue can lead to performance degradation in
IBM BPM Advanced.
For instructions on enabling automatic monitoring of the WebSphere
Application Server SIBus queue depth, see the following web document:
http://www.ibm.com/support/docview.wss?uid=swg21618858
When IBM BPM is interfacing with external systems, monitor the network
traffic between these systems for potential response time delays. We
suggest that you consider using packet tracing tools (approved by your
company) for monitoring the network traffic. We also suggest that you
consult with the team monitoring the external systems themselves, to see
if there are any issues with those systems.
7.5 Conclusion
In this chapter, we described the following topics:
Performance tuning process flow that can be used as a reference for ongoing
performance tuning activity in IBM BPM
Concepts of IT-centric visibility and important considerations of IT-centric
visibility that can affect reliability, availability, and scalability (RAS) of systems
or applications
Performance diagnostic tools that can be used for collecting and analyzing
key performance metrics in IBM BPM
Sample use cases highlighting the use of performance diagnostic tools in
addressing some of the commonly reported performance issues in IBM BPM
The publications listed in this section are considered particularly suitable for a
more detailed description of the topics covered in this book.
IBM Redbooks
The following IBM Redbooks publications provide additional information about
the topics in this document. Note that some publications referenced in this list
might be available in softcopy only:
Scaling BPM Adoption: From Project to Program with IBM Business Process
Manager, SG24-7973
Applying Lean, Six Sigma, BPM, and SOA to Drive Business Results,
REDP-4447
Business Process Management Deployment Guide Using IBM Business
Process Manager V8.5, SG24-8175
Creating a BPM Center of Excellence (CoE), REDP-4898
IBM Business Process Manager V8.0 Performance Tuning and Best
Practices, REDP-4935
IBM Business Process Manager V8.5 Performance Tuning and Best
Practices, SG24-8216
Process Discovery Best Practices Using IBM Blueworks Live, REDP-5111
Leveraging the IBM BPM Coach Framework in Your Organization,
SG24-8210
IBM Business Process Manager Security: Concepts and Guidance,
SG24-8027
IBM Business Process Manager Version 8.0 Production Topologies,
SG24-8135
Understanding LDAP - Design and Implementation, SG24-4986
Empowering your Ad Hoc Business with IBM Business Process Manager,
REDP-4995
248 Business Process Management Design Guide: Using IBM Business Process Manager
Business Process Management Design Guide: Using IBM Business Process Manager
(0.5 spine)
0.475<->0.875
250 <-> 459 pages
Back cover
SG24-8282-00
ISBN 0738440590
Printed in U.S.A.
ibm.com/redbooks