WHITE P APER

Workflow, Rules, and CEP Combine to Drive New Business

Value
Sponsored by: Red Hat
Maureen Fleming

Kate Silverstein

Global Headquarters: 5 Speen Street Framingham, MA 01701 USA

P.508.872.8200

F.508.935.4015

www.idc.com

October 2012

EXECUTIVE SUMMARY
Many of the largest business process management (BPM) projects span the
organization and involve a shift from manual to automated tasks, back-end
orchestration, extensive use of rules, event-driven problem detection, and more
dynamic capabilities that support knowledge workers. Aligning software
comprehensively with the varied facets of process improvement has changed the
core focus of BPM software. In BPM projects, rules and events are just as
important as and often more important than workflow.
A key to successful process improvement projects is ongoing and effective
collaboration between business and IT. This collaboration includes the selection
of the platform, design of process improvements, and development of new or
improved processes.
BP platforms are relatively closed environments in that enterprises will not easily
swap one platform for another. That is why enterprises need to pay attention to
the use of open standards when selecting a platform.
Red Hat's JBoss Enterprise Business Rules Management System (BRMS) 5.3
combines process modeling with workflow, rules, and complex event processing
(CEP) into a single open source distribution. Its Web and Eclipse-based tooling is
designed to foster improved collaboration between business and IT stakeholders.
With the acquisition of Polymita, Red Hat has added case management to its
portfolio of offerings, along with advanced monitoring and simulation capabilities.
The combination of technologies allows Red Hat to address a broad range of
process improvement use cases. Red Hat's open source, standards-based
offerings provide extensive capabilities at a lower cost relative to other products
on the market today.

SITUATION OVERVIEW
Over the past few years, enterprises have broadened the role BPM software plays in
process improvement. Five years ago, BPM projects centered on human-centric
workflow designed and executed with process models.
Since then, lines of business continue to demand software that is more adaptive to
how they work, and vendors have responded with increasingly mature offerings.
Meanwhile, implementation teams have become more knowledgeable about and

adept at using BPM software. Today, many of the largest BPM projects span the
organization and involve a shift from manual to automated tasks, back-end
orchestration, extensive use of rules, event-driven problem detection, and more
dynamic capabilities that support knowledge workers.
While improving productivity with a human-centric task workflow continues to be
important, we are seeing significant growth in strategic projects using BPM software
to support knowledge-centric, highly variable work and as an orchestration layer on
top of a group of applications that manage a larger end-to-end process. These BPM
projects are implemented in support of critical initiatives, including:
Improving responsiveness to customers by reengineering the coordination of
supporting back-end systems
Driving down the cost of a process by making the process more predictable and
efficient
Improving the overall responsiveness of large packaged applications by
extending them, adding needed new capabilities using BPM software
Aligning software comprehensively with the varied facets of process improvement has
changed the core focus of BPM software. Rules and events are just as important as
and often more important than workflow.
Collaborating on a process model has always been an important aspect of process
improvement using BPM software. With the growing sophistication, teams are greatly
extending their focus to collaborate on:
The design of an end-to-end process and identification of problems that can
cause a process failure. This involves the ability to create models that describe
how the process should operate and conditions that, if not met, will result in a
failure. Adding this type of intelligence to a process gives the business an
opportunity to operate more consistently and predictably.
Decisions that need to be made as part of the process, and whether those
decisions can be made automatically through the adoption of rules or whether
they are made by process participants with supporting data collected and made
available to the user as part of the application design.
Whether the design of the set of activities required to complete work can be
described in workflow or whether task completion is unpredictable. With the
latter, managing task state becomes critical to the success of the process
improvement effort. The core of the model switches from workflow to state
changes and rules.
To be successful, enterprises need to take into account basic requirements and how
those requirements are changing in the face of the broadening scope of BPM
software inside their organization. The tools that help foster collaboration between
business and IT are also important.

#237258

2012 IDC

Evolving Business Process Platforms

BPM-style automation is constructed from several core technical elements that, when
combined, allow an enterprise to describe a process, link workers to the process and
assign them work, provide workers with a user interface (UI), manage the status of
work in progress, and govern the process.
A BP platform consists of building blocks that are combined from these lower-level
elements to provide reuse and out-of-the-box capabilities to make it faster and easier
to design and automate process improvement. Figure 1 illustrates the components
that enterprises commonly put together to build and manage their process platform.

FIGURE 1
Business Process Platforms

User Interface
Case

Project

Work Management
Decision Automation

Analytics

Rules

CEP

Execution

Workflow

Case Mgmt

Process Discovery, Design,

Development, and Life Cycle

Monitoring, Reporting, and

Performance Management

Task

Orchestration
Content Mgmt

Integration Services

Source: IDC, 2012

User Interface
The user interface of a BP platform supports PCs and mobile devices, with the UI
capable of rendering the style of interface appropriate for both the information and the
activities required of the process design. Workers may need a simple task UI to
approve something; they may need a full view of all activities, including any
outstanding activities required to complete work, as well as full access to documents
and data required to make a decision. These task-style UIs are often far more
complex than the tasks. In addition, projects may include embedded cases with
embedded tasks. The UI must support all of this logic, allowing for intuitive interfaces
across different endpoints.

2012 IDC

#237258

Work Management
Work management determines how to route work. Workers can be added to a custom
directory managed by the platform or accessed from a directory service. Workers in a
directory are assigned to roles. Rules are used to determine holiday schedules, work
routing when someone is on vacation, routing for the correct time of day, etc.
Work management becomes more interesting in an organization with matrices, when
tasks need to be passed beyond the hierarchical control of the directory service. The
rules for escalation and accountability need to be built into work management. Before
a process is moved into production, work management needs to be designed and
implemented. It is more common to see enterprises construct work management as a
layer in their BP platform to improve reuse of the logic.

Decision Automation
Different types of decision automation are used to support process automation. Rules
play an active role in the technology of process improvement, but they also are
heavily used by business users who benefit from better performance at the business
level. Examples include:
Governance and compliance. Rules are used in governance to ensure an
organization is complying with internal standards, external regulations, and
customer service-level agreements (SLAs).
Improved process efficiency and consistency. Rules can be used to
automate certain decisions. When the burden of decision making is shifted from
people to systems, the logic behind each decision can be traced back to the logic
contained in the rule, and the same logic can be applied to all decisions. This
improves process consistency.
Enterprises are orchestrating work across multiple applications. When rules are
coupled with events, they can supplement orchestration by detecting problems that
can trigger a set of activities to achieve a resolution. It is increasingly common to
construct a process model that describes the end-to-end process along with
swimlanes or channels that listen for problems. When a problem is detected,
work may be suspended while the problem is resolved and then canceled or resumed
depending on the resolution.
There are a variety of techniques to detect problems with a process, such as setting
time limits in process design or key performance indicators in business monitoring. In
both cases, when the activity or business performance falls out of bounds, a trigger
escalates the problem.

Runtime Execution
A BP platform needs to coordinate the core execution of the process, including
managing all services that fit together to solve all of the logic elements of the process
design.

#237258

2012 IDC

Orchestration
There are also many types of problems that are not easily described in simple out-ofbounds logic. Problems that are identified through the passage of time or physical
movement require a comparison of multiple sequential events to determine whether
the set of events represents a pattern that describes a problem or an opportunity.
For example, when drivers use a navigation system, they are able to enter both the
address of their current location and the address of where they would like to be. The
navigation system calculates the best route and estimates arrival time. As they follow
the instructions, the navigation system tracks to ensure they are continuing on the
proper route and identifies a wrong turn immediately, providing corrections and
reestimating time of arrival.
In business today, enterprises use CEP as core technology to describe and monitor
complex patterns, identifying when they take the functional equivalent of a wrong turn.
Fraud detection, outage detection, event-driven marketing recommendation engines,
and enrollment completion all rely on correlating events over time. Dispatch, real-time
customer service, and logistics are all examples where process improvement with
both time and location sensitivities relies on CEP.
When the problem triggers an investigation, a case can be created and assigned to
someone for resolution. That person will need to add tasks, collect information,
perform analysis, and possibly collaborate with additional workers to solve the
problem. BP platforms increasingly integrate with analytical applications and business
intelligence for contextual, embedded decision support.
The BP platform needs to keep track of the state of all of these manual and
automated decisioning activities, manage any documents that are added, present
information to the user or team working on the case, and capture the decision and
push it to the main task to cancel or reactivate the suspended work in process.
To enable these capabilities, an orchestration layer often sits between integration and
Web services and the execution environment. Orchestration manages the handoff of
tasks and data between systems associated with the process and keeps track of
whether everything has been properly handed off.

Access and Integration

Access and integration capabilities allow the system to call Web services, retrieve
data, and provide access to content repositories and file storage systems and
services.
Although most enterprises look for commercial offerings that pull many of these
elements together in an integrated development and runtime environment, all of the
core elements that create a BP platform can be constructed from the open source
community. Enterprises often supplement open source offerings with technology
development or commercial offerings required to fill out their platform.

2012 IDC

#237258

Common BPM Deployment Patterns

BPM projects vary because needs vary by industry, by business initiative, by scope,
and by design goal. Two companies may adopt a BP platform to improve customer
service, for example. One project may be devoted to improving the customer
experience during a call center interaction, and the other may be focused on
preventing the need for customers to call in with a complaint.
The two projects involve completely different designs and runtimes. However, both
use the underlying principles of BPM software collaborative design and
development with role-based tooling, configuration of properties, avoidance of
custom code, and agile methodology.
Enterprises new to BPM often opt to identify and start on projects that are relatively
straightforward. Frequently, they are learning about the technology, the proper
implementation methodology, and how to establish an effective team consisting of
business and IT participants.
Those projects are often tied to cross-departmental activities, such as approvalcentric workflow, or custom departmental process applications. As the technology is
better understood and the kinks in the business/IT relationship are worked out, there
is a move to more sophisticated projects that involve more integration across a
broader set of applications.
In discussions with customers about successful projects, we have noticed common
types of projects, which we have organized as follows:
Task management
Process application
Composite process application
Business process backbone

Task Management
Enterprises often have trouble managing processes that are not highly repeatable
and that are difficult to automate. As a core capability, BP platforms provide software
that allows enterprises to better manage these kinds of processes as tasks. Based on
a workflow, the platform keeps track of a task's flow, from kickoff through escalations
and approvals to completion.
Generally, task management deployments involve little or no integration with systems
of record and have a simple and well-defined set of requirements. For example, a
company might use task management to support a budgeting cycle radiating from the
finance group through lines of business and down through the organization.
Other types of task management include travel approvals, content change approvals,
and employee onboarding. The latter group involves interfacing with people and with
systems that manage the myriad aspects required to ensure that employees are fully
provisioned and ready to work.

#237258

2012 IDC

Process Application
Enterprises commonly use BP platforms to build enterprise applications that involve
automating a process. In this case, there is a desire to reduce development costs,
have business and IT collaboration in the design and development, improve time to
value, and increase adoption rates.
Enterprises make decisions about how to implement based on whether the
application has strong workflow requirements or whether the work needs to be
organized around ad hoc activities that are determined by the knowledge worker.
Many applications operate in the middle ground where an overarching workflow is
punctuated by highly ad hoc activities.
For example, a real estate agency has built a process application around due
diligence based on a BP platform. Field agents send information about newly
procured properties back to the accounting department via an electronic form. The
application routes the form to the appropriate place and makes it easy for
accountants to find the information they need to make estimates about renovation
costs and other aspects of due diligence.

Composite Process Application

Enterprises are increasingly improving their processes through the adoption of
composite process applications. These sorts of applications use existing functionality
and data and focus on minimizing net-new development. They typically standardize
the user interface and orchestrate the coordination of data and Web services to
deliver the appropriate information to the user interface and to pass tasks and
requests to applications and business services.
Composite process application projects generally involve a standardized, role-based
user interface, integration, rules, work management, and browser interfaces. We are
also seeing much broader extension to mobile devices.
For example, a major life insurer built a composite process application on top of a
BP platform to replace a legacy application that call center representatives used to
handle customer service requests. The project centralized several information feeds
from different administrative systems into a single user interface in order to reduce
the number of screens and applications that call center representatives had to touch
in order to handle a request.

Business Process Backbone

To increase the efficiency and adaptability of supporting complex, heterogeneous
application environments, enterprises are building backbones that receive work,
process work, and deliver tasks and data to existing applications. These backbones
become standardized processing utilities for the families of applications and workers
associated with the backbones. Functionality required to implement processing
backbones includes work management, integration, orchestration, and monitoring.
Backbones are increasingly built for customer onboarding for standardization of
outbound customer communications. For example, the implementation of a backbone

2012 IDC

#237258

required a large bank to transform its application-centric architecture into a

horizontally layered service-oriented architecture (SOA). The bank's IT architecture
was broken into separate layers around business logic, legacy services, and
integration. A BP platform was implemented on top of the technical layers to execute
business processes. Further, on top of the business process layer, service center
employees used a front-end application to monitor end-to-end progress of the work.

Rules and Events Team Up with Process Model

and Workflow in Red Hat BRMS 5.3
Red Hat entered the BP platform market with the release of JBoss Enterprise BRMS
5.3 in June and with the acquisition of Polymita in August.

BRMS 5.3
BRMS 5.3 is a single distribution Java standard BP platform built around rules,
workflow, and CEP. It also supports the BPMN 2.0 standard for process modeling and
execution. Combined with tools designed for business users, BRMS 5.3 is capable of
supporting business and IT collaboration across a broad array of process
improvement initiatives. This includes both structured processes and ad hoc activities
designed and generated by end users.
Similar to other Red Hat offerings, the basis of BRMS 5.3 is a community offering. BRMS
5.3 is built from Drools 5.2. It is offered as a subscription and includes packaging of the
software, testing, regular security patches, updates, and customer service.
BRMS 5.3 is priced at a fraction of the license and maintenance costs of comparable
offerings from closed source vendors.
Enterprises that already have standard user interface development tools are able to
use BRMS 5.3 as the back-end process development environment and execution
engine. This combination allows enterprises to extend existing applications and to
build new applications that support the company's user interface design and branding.
Business User Process and Rules Tools

Business users are provided with a rules authoring environment that supports decision
tables along with the ability to use Microsoft Excel and OpenOffice Calc to define rules.
In addition, browser-based process modeling is available for use by business analysts
and other users, without requiring the installation of the standard Eclipse-based
development environment.

Polymita
Polymita falls into the sweet spot of the BPM market, where business users see its
advantages and developers have enough functionality to implement solid process
applications.
Polymita provides Red Hat with a Java-based suite that includes modules for process
management, content management, portal development, business rules, business

#237258

2012 IDC

activity monitoring, and enterprise application integration. The suite also includes
FreeFlow for developing unstructured or ad hoc processes as well as simulation
capabilities.
Red Hat's BPM solutions will likely derive benefit from the key strengths of Polymita,
including a well-featured set of capabilities able to handle both case management and
task management. Polymita has a top rating from IDC (see IDC MarketScape:
Worldwide Business Process Platforms 2011 Vendor Analysis, IDC #228598) for ease of
use and for its broad set of capabilities.

ESSENTIAL GUIDANCE
Collaboration and Process Improvement
When business process improvement efforts involve automation, there is often
tension between those who understand and manage the process and the
implementation team. The process participants work hard to describe what the
process improvement should be, and the development team interprets.
Business users are somehow expected to have a perfect understanding of what they
need before development begins. Meanwhile, developers are often required to be
mind readers. This is an age-old problem that needs to be solved. As result, we have
seen significant changes to methodologies and tooling to support a greater degree of
collaboration between business and developers through all the phases of a process
improvement initiative.
BPM software is increasingly selected by enterprises as the environment and platform
of choice for collaborative design and development for process automation. A key
reason for the increase in popularity is the growing maturity of tooling that is used for
collaboration as well as the focus on automation with minimal to no custom code. Built
around graphical user interfaces, BP platforms allow the development team to describe
the business process model, declare the rules, and design user interfaces as a team. In
discussions with enterprises of all sizes across all regions that have used BPM
software for process improvement, we consistently hear the following benefits:
Better acceptance by process participants
Less change once the new automation is deployed
Lower cost of change when it is required
Ability to deliver value sooner than an equivalent project involving custom code
Lower development costs and faster implementations mean that process automation
can be applied to smaller teams or business units because they can meet ROI
thresholds that were previously unattainable.
The most successful projects involve participation from both the business team and
the development team across all phases of a process change, from selection of the
BPM software through design, development, testing, and acceptance.

2012 IDC

#237258

We have enumerated the strengths and successes using BP platforms throughout

this paper:
Greater acceptance when process automation is collaboratively developed
Faster time to value
Ability to generate a positive ROI on much smaller projects, supporting the long
tail of process improvement
Empowers the business to manage change and leads to greater business agility
Challenges include:
Forming a working team consisting of business and IT
Identifying a good starting point
Determining requirements and aligning software selection with those requirements
Learning how to work within the boundaries of the platform to minimize customization

Recommendations
The most common recommendations from enterprises with expertise in use of BP
platforms include:
BP platforms are relatively closed environments in that it will not be easy for an
enterprise to invest in one platform and easily migrate to another. When selecting
a BP platform, pay attention to the platform's support of standards, such as
BPMN 2.0 for process modeling, as well as standards-based frameworks and
development environments in order to mitigate the risk of lock-in.
Understand and plan for a learning curve for the initial projects that cover both
technical and cultural issues.
Invest in training.
Because of the learning curve, it is important to deliver a win quickly. Pick a
portion of an important and visible process that can be designed and automated
in a relatively short period of time and use it as a foundation for improving the
larger process in a series of steps.
Many IT organizations that want to invest in BPM but do not have a business
process owner culture amenable to BPM choose to implement their first process
internally within IT to test and learn. Under these circumstances, targeting
processing backbones or IT processes as initial projects would provide the
necessary understanding of how a BP platform fits in your environment.
Resist the urge to customize until you are fully certain that there is no other way to
achieve the desired result. Once you customize, it becomes increasingly difficult to
upgrade the core platform or change the process. Because BPM is all about being

10

#237258

2012 IDC

able to change as needed, customization is the enemy of a well-run process. If you

have to customize, make sure the change fits architecturally in the platform and is
isolated enough to allow for upgrades and improvements to the platform.
Whether you are implementing a process improvement with business process
owners or within IT, make sure you implement monitoring and reporting to gain
an understanding of the process status. Process visibility is a good tool to show
to management to gain interest and momentum.
Make sure your development team includes representatives from both business
and IT. Make sure everyone knows what their roles and obligations are. Meet
often. Expect change.
After a successful initial project, make sure the development team remains intact
for the follow-on projects. Eventually, you will be able to document and build a
plan for process improvement. That plan should include both methodology and a
team of experts.

CONCLUSION
Organizations are adopting BP platforms strategically for competitive differentiation as
well as to speed up cycle times in a way that mitigates the risk of operating at a faster
pace. While these benefits are significant, BP platforms that embrace workflow, case
and state management, rules, and CEP offer an opportunity to align end-to-end
processes with customer expectations of service levels, internal expectations of
operational efficiency, and support of regulated environments.
Regulatory standards and customer SLAs present enterprises with similar problems
in terms of compliance because they often require similar technology solutions:
process automation for error reduction and faster cycle times, rules to ensure that
requirements are being met and that errors are being handled correctly, and CEP to
catch and solve problems before they leak out to customers or auditors.
Building out a BP platform to support a broad array of process improvement initiatives
requires an expanded focus to include incorporation of the different patterns used to
improve both structured and ad hoc processes across devices.

Copyright Notice
External Publication of IDC Information and Data Any IDC information that is to be
used in advertising, press releases, or promotional materials requires prior written
approval from the appropriate IDC Vice President or Country Manager. A draft of the
proposed document should accompany any such request. IDC reserves the right to
deny approval of external usage for any reason.
Copyright 2012 IDC. Reproduction without written permission is completely forbidden.

2012 IDC

#237258

11