BPM WP FileNET
BPM WP FileNET
BPM WP FileNET
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
A Delphi Group White Paper<br />
<strong>BPM</strong>2003<br />
Market Milestone Report<br />
Contents<br />
Methodology ............................ 2<br />
Defining <strong>BPM</strong> ........................... 4-6<br />
Process Orchestration ............ 7<br />
Phases of Orchestration ......... 8<br />
Orchestration &<br />
Virtualization ........................... 9<br />
Orchestration Summary ........ 10<br />
Components of <strong>BPM</strong> ............... 11<br />
What’s Missing From<br />
Current Offerings .................... 12<br />
Product Selection Criteria ..... 13<br />
Defining Business Logic......... 14<br />
<strong>BPM</strong> Benefits ............................ 15<br />
Integration Priorities ............. 16<br />
Requirements for<br />
Software Suppliers .................. 17<br />
Current State of<br />
<strong>BPM</strong> Deployments ................... 18<br />
Investment Size &<br />
Pricing Models ......................... 19<br />
<strong>BPM</strong> Market Size &<br />
Momentum ............................... 20<br />
Platform Expectations ............ 21<br />
<strong>BPM</strong> Standards ........................ 22-23<br />
Fuego<br />
Product Assessment ................ 24-27<br />
Tesoro<br />
Case Study ................................ 28-30<br />
Fuego, Inc.<br />
2400 Dallas Parkway<br />
Plano, TX 75093, USA<br />
P (972) 801-4200<br />
F (972) 801-4201<br />
www.Fuego.com<br />
Featuring a Delphi Group<br />
Assessment of:<br />
Enabling the New Mission for IT<br />
Today's IT challenges are defined as much by what is in place already as<br />
by what might be missing. We have lived through the "killer app" era,<br />
having spent the last two decades building islands of automation with<br />
packaged software. But the legacy left by these systems is an integration<br />
problem that today consumes the lion's share most IT budgets.<br />
While the challenge of integration remains largely unsolved, it has<br />
nonetheless moved further to the forefront after years of custom<br />
application development, a rising tide of regulatory pressure (now<br />
presenting criminal liability thanks to the Sarbanes-Oxley Act), and for<br />
many firms a morass of system complexity after waves of M&A activity.<br />
Forced to contend with these new challenges in the face of IT dollars<br />
being increasing consumed by integration and maintenance costs, it is<br />
of no surprise that Business Process Management has seen such a rapid<br />
rise in interest over the past year. Yet the real value of <strong>BPM</strong> is not simply<br />
that of a cheaper means for integration, but rather as a resource to<br />
channel existing automation into orchestrated business processes.<br />
Today we are also on the cusp of what may very well be the final great<br />
boom of the software industry, and the last frontier for generating value<br />
from IT infrastructure. Born from the need to keep pace with a<br />
continuously changing business environment, this phase will be led by a<br />
new mandate for software virtualization, componentization, and<br />
orchestration.<br />
If this is starting to sound like Web services, it should. But to lay this<br />
entire opportunity at the feet of Web services would miss the point<br />
entirely. Web services are an enabler, not an end-state. Simply exposing<br />
applications as services will take us little beyond where we are today.<br />
As is illustrated in this report, the true linchpin for the realization of<br />
this opportunity is the ability to connect these components through a<br />
framework of orchestrated business processes --- to transform automation<br />
infrastructure into reusable business assets. This is the new charter for<br />
the partnership of business and IT, and the real value offered by today’s<br />
generation of <strong>BPM</strong> software.
2<br />
Methodology<br />
This report is based on a combination of a recent<br />
Delphi survey and additional analysis by Delphi<br />
Group's research team.<br />
The charts in this report present the findings from<br />
the Q2’03 survey with responses from 500<br />
individual users and evaluators within firms<br />
across multiple industries worldwide.<br />
Approximately 75% of responses are from the U.S.<br />
Respondents varied in their roles from current<br />
users of <strong>BPM</strong> to project sponsors and business<br />
analysts. Approximately 75% of respondents are<br />
presently engaged in either deploying or<br />
evaluating <strong>BPM</strong> software.<br />
The Q2’03 survey follows a Q4’01 research<br />
initiative executed for the 2002 <strong>BPM</strong> Market<br />
Milestone Report. At specific points in this year’s<br />
survey, questions are intentionally repeated from<br />
the Q4’01 survey to demonstrate and validate the<br />
evolving opinions, attitudes and behaviors within<br />
the <strong>BPM</strong> market. Where this was done, charts and<br />
data are presented with both years’ findings<br />
juxtaposed to demonstrate contrast.<br />
Throughout this report, the survey findings are<br />
presented to illustrate concepts and trends, in<br />
addition to the quantified results represented<br />
within the charts. As definitions and perspectives<br />
vary between individuals and across organizations,<br />
examining the contrast in responses offers clearer<br />
reflection of the true state of the market than any<br />
single statistic alone.<br />
Sponsor Initiative(s)<br />
(15%)<br />
Evaluate <strong>BPM</strong><br />
Solution<br />
(6%)<br />
Identify<br />
Requirements<br />
(13%)<br />
Sponsor<br />
<strong>BPM</strong><br />
Initiative(s)<br />
(19%)<br />
Current Role With<br />
<strong>BPM</strong> Deployments<br />
Develop <strong>BPM</strong><br />
Software (3%)<br />
Acquire <strong>BPM</strong> Solution<br />
(Not Sponsor) (9%)<br />
<strong>BPM</strong><br />
End User<br />
(44%)<br />
Lead or Participate<br />
on Deployment Team<br />
(10%) None (3%)<br />
None (10%)<br />
Future Role With<br />
Future <strong>BPM</strong> Deployments<br />
End User<br />
(19%)<br />
In the final stage of this research initiative, Delphi<br />
Group’s research interviewed a set of <strong>BPM</strong> software<br />
vendors and their customers. The results of these<br />
interviews have shaped the analysis presented in<br />
this report, and are also presented at the end as a<br />
set of individual case studies and product profiles.<br />
Define IT<br />
Specifications<br />
(23%)<br />
Define<br />
Business<br />
Requirements<br />
(25%)<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
3<br />
Report Highlights<br />
<strong>BPM</strong> = Workflow + EAI 4<br />
The Anatomy of<br />
Process Management 4<br />
Orchestration vs. Automation 7<br />
Web Services and<br />
Process Orchestration 7<br />
Process Orchestration<br />
Myths and Realities 10<br />
Whole-Product Requirements 11<br />
Market’s Perspective 12<br />
Product Selection Criteria 13<br />
Business Software for a<br />
Business Audience 14<br />
What’s in it for IT? 15<br />
Integration Priorities:<br />
The Market’s Perspective 16<br />
Who Gets The Deal? 17<br />
The Market Comes of Age 18<br />
How Big a Deal? 19<br />
How Big is the Market? 20<br />
Deployment Platforms for Current<br />
and Future <strong>BPM</strong> Initiatives 21<br />
The Role of Standards in <strong>BPM</strong> 22<br />
Product Assessment: Fuego 24<br />
Case Study:<br />
Tesoro 28<br />
Table of Charts & Figures<br />
Current Role With <strong>BPM</strong> Deployments 2<br />
Future Role in With Future<br />
<strong>BPM</strong> Deployments 2<br />
Current Definitions of <strong>BPM</strong> 4<br />
Figure 1 - Conceptual Model of <strong>BPM</strong> 6<br />
Figure 2 - An Automated Process 9<br />
Figure 3 - An Orchestrated Process 9<br />
Process Management Software Landscape 10<br />
Necessary Components of Any <strong>BPM</strong> Solution 11<br />
Features Missing From <strong>BPM</strong> Solutions 12<br />
Overall Functional Priorities Driving<br />
Product Selection Criteria 13<br />
Project Sponsor for <strong>BPM</strong> Investments 14<br />
Responsibility for Defining Business<br />
Rules & Process Logic 14<br />
Single Greatest Functional Advantage<br />
Anticipated from <strong>BPM</strong> 15<br />
Single Greatest IT-Specific Benefit<br />
Anticipated from <strong>BPM</strong> 15<br />
Integration-Specific Priorities<br />
Driving Product Selection Criteria 16<br />
Direction of Increasing Priority 16<br />
Financial Criteria for <strong>BPM</strong> Software Suppliers 17<br />
Investment Timing for Firms Without<br />
Current Deployments or Initiatives 18<br />
State of <strong>BPM</strong> Deployments 18<br />
Reasons Cited for Not Investing in <strong>BPM</strong> 18<br />
Preferred Pricing Model for <strong>BPM</strong> Investments 19<br />
Total <strong>BPM</strong> Software-Only Spending<br />
Anticipated Over the Next Three Years 19<br />
Financial Role for <strong>BPM</strong> Deployments 19<br />
Total Anticipated 2003 Spending on <strong>BPM</strong> 20<br />
Services/Hardware vs. Software 20<br />
Anticipated Platform for Future<br />
<strong>BPM</strong> Deployments 21<br />
App Server Choices for Future<br />
<strong>BPM</strong> Deployments 21<br />
Recognition of Existing <strong>BPM</strong><br />
Standard Initiatives 22<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Defining <strong>BPM</strong><br />
4<br />
<strong>BPM</strong> = Workflow + EAI<br />
Nearly half of respondents to the 2003 survey<br />
identified most closely with the definition of <strong>BPM</strong><br />
as an emerging software layer for building processbased<br />
applications. This is an increase over 2001<br />
and represents a better than 5-to-1 advantage<br />
over any other answer.<br />
This reflects the fundamental shift towards crossfunctional<br />
processes (i.e., across multiple<br />
applications). After spending two decades building<br />
“islands of automation” with packaged software,<br />
organizations today are looking to bridge the gaps<br />
these have left across operational processes.<br />
The growing trend to address this has been greatly<br />
influenced (and vice versa) by changes in software<br />
development that have led to easier separation<br />
of business processes from applications, fueled<br />
in no small part by the Internet and Web services.<br />
In the same manner that the emergence of SQL<br />
and the two-tier client/server architecture enabled<br />
the abstraction of data management from<br />
application code, the emergence of N-tier<br />
computing and component-oriented environments<br />
(such as COM and J2EE) allow for the abstraction<br />
of business processes from application logic.<br />
By separating business process management as<br />
an independent function, applications can be<br />
designed around existing processes, and thus to<br />
take advantage of shared business logic rather<br />
than reinventing and recoding it for each<br />
application.<br />
An emerging layer of<br />
software for building new<br />
process-based applications<br />
Just rebranding<br />
of old-style workflow<br />
A subgroup of EAI software<br />
The latest buzzword<br />
about to be dominated<br />
by Microsoft, IBM, SAP, et al<br />
Have no strong opinions<br />
too early to tell<br />
©2003 Delphi Group<br />
Current Definitions of <strong>BPM</strong><br />
12.3%<br />
19.4%<br />
11.7%<br />
12.1%<br />
4.4%<br />
4.8%<br />
12.3%<br />
9.7%<br />
59.2%<br />
54.0%<br />
2003 Survey<br />
2001 Survey<br />
0% 10% 20% 30% 40% 50% 60%<br />
The notion of cross-functional processes<br />
inevitably brings to mind application integration,<br />
which is no doubt responsible for much of the<br />
confusion between <strong>BPM</strong> and EAI. With these<br />
results, however, the market shows a clear and<br />
appropriate bias towards the independence of <strong>BPM</strong><br />
from EAI or data-centric integration software.<br />
While the market seems clear on this distinction,<br />
<strong>BPM</strong> has nonetheless been pigeon-holed by many<br />
analyst firms as merely a subgroup of EAI. To do<br />
so, however, is to miss the point of <strong>BPM</strong>’s<br />
fundamental value to the enterprise.<br />
<strong>BPM</strong> is not about linking applications, per se, nor<br />
about defining the transformation logic involved<br />
in extracting data from applications. This may be<br />
a subset of what a <strong>BPM</strong> solution offers, yet the real<br />
value of <strong>BPM</strong> is the ability to define and execute<br />
business processes independent of applications<br />
and infrastructure. While EAI and integration<br />
capabilities offer an important resource to <strong>BPM</strong><br />
environments, integration software typically lacks<br />
the ability to address the user-facing side of<br />
business processes. This is consistent with the fact<br />
that EAI is concerned foremost with app-to-app<br />
exchange of data, not user activity or interaction.<br />
The Anatomy of Process Management<br />
To make sense of how <strong>BPM</strong> fits with organizations<br />
and infrastructure, it is helpful to examine the<br />
individual components of <strong>BPM</strong>. While commercial<br />
systems vary in their specific definitions and<br />
software composition, most fit within the basic<br />
framework described below. Note that although<br />
some systems (ERP and HRMS for<br />
example) offer the ability to automate<br />
activities and define business rules, those<br />
that lack the fundamental components<br />
below cannot realistically be used as a <strong>BPM</strong><br />
system.<br />
A <strong>BPM</strong> system is defined by the<br />
components of an Execution Engine,<br />
Process Designer, Process Definitions, an<br />
Activity Monitor, and user interface which<br />
may be a combination of Windows client<br />
application, HTML-based Work Portal, or<br />
an exposed API or Web service (see the<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Defining <strong>BPM</strong><br />
5<br />
model on page 6 for an illustration of how these<br />
pieces work together).<br />
For the vast majority of <strong>BPM</strong> systems on the<br />
market today, application architectures are<br />
component-oriented and allow each of the<br />
individual pieces listed above to be deployed<br />
independently on individual servers, or (albeit<br />
less commonly) as COM or EJB components.<br />
Individual business processes are defined in a<br />
Process Definition and increasingly expressed in<br />
some variation of XML (additional details on XML<br />
standards for Process Definitions are provided in<br />
the ‘Standards’ section of this report, pages 22-23).<br />
Each Process Definition may be composed of both<br />
Manual Activities and Automated Activities. Once<br />
defined and validated within the Process Designer,<br />
Processes are instantiated by an Execution Engine.<br />
An instantiated Process Definition is a Process<br />
Instance. The state, status and history of each<br />
Process Instance are persisted into an external<br />
data store (this is true today of any commercially<br />
viable <strong>BPM</strong> system as none use internal databases<br />
as early systems once did). The Activity Monitor<br />
provides access to status and performance metrics<br />
on the execution of Process Instances. While all<br />
systems provide some form of an Activity Monitor<br />
or reporting mechanism, they vary according to<br />
the degree of control over granularity of reports<br />
and whether or not “live” data can be accessed.<br />
The Execution Engine controls the state and<br />
execution of each Process Instance, which are<br />
composed of multiple Activity Instances. Activity<br />
Instances represent the process activities (also<br />
called Tasks or Steps) during execution, and<br />
include both Work Items and Invoked Applications.<br />
Invoked Applications are automated<br />
activities involving some form of a system-tosystem<br />
transaction, such as a stored procedure<br />
or a Web service.<br />
Work Items are manual activities distributed<br />
to human users or process participants. These<br />
may be a process exception that requires<br />
manual intervention, or a process step that by<br />
definition always requires human input.<br />
When a process instance is executed, Work Items<br />
are generated in response to activities and process<br />
rules, and distributed by the Execution Engine into<br />
an appropriate user’s Work List. The Work List is a<br />
collection of Work Items from one or more process<br />
instances, each with its own state and status. Work<br />
lists represent the integration between process<br />
participants and process instances. Process<br />
participants access Work Items from the work list,<br />
which is coordinated by the Execution Engine.<br />
In this way (i.e., managing the exchange of Work<br />
Items between users and systems) process<br />
management is undeniably similar in appearance<br />
to message queuing and other asynchronous<br />
approaches to application integration (EAI).<br />
Yet it should be understood that managing<br />
processes is not about data flow or moving data<br />
from one bucket to another, nor responding to<br />
discrete events in isolation, but managing flow<br />
control across an entire business process instance.<br />
The ability to include manual activities as part<br />
of the process (i.e., rather than simply part of an<br />
error handling routine) is a subtle but significant<br />
point of differentiation between <strong>BPM</strong> and EAI.<br />
Generating Work Items and managing Work Lists<br />
requires the Execution Engine to have access to<br />
user identities (i.e., through Directory Services)<br />
and access privileges. Roles and interrelationships<br />
(such as team structures) can be defined and<br />
managed within the <strong>BPM</strong> system, but architecture<br />
of most systems on the market today leverage<br />
authentication and directory services from<br />
existing infrastructure using standard interfaces<br />
such as LDAP, JNDI and Active Directory.<br />
Handling Work Items is a critical role of the<br />
Execution Engine and underscores the importance<br />
of managing manual activities (Work Items)<br />
separately from transactional activities (Invoked<br />
Applications). For example, ensuring the integrity<br />
of executed processes requires both the ability to<br />
initiate compensating actions if a transaction fails<br />
and to identify when a specific activity requires<br />
human intervention. This requires a broader<br />
perspective (i.e., process-wide) than is otherwise<br />
provided from individual transactions.<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Defining <strong>BPM</strong><br />
6<br />
For example, the J2EE framework offers an 'ACID'<br />
test for the integrity of discrete transactions<br />
(defined vis-à-vis the four properties of Atomicity,<br />
Consistency, Isolation, and Durability). This is an<br />
important enabler for the <strong>BPM</strong> system to ensure<br />
the integrity and completion of individual process<br />
steps. However, ACID as a specification does not<br />
adequately address the need for state management<br />
across long-running transactions and business<br />
processes. Similarly, while J2EE session beans<br />
enable state to be held or passed from one<br />
transaction to another, they are not capable of<br />
managing higher-level business logic or flow<br />
control across the execution of a process.<br />
Rather, this level of control and coordination<br />
requires an Execution Engine to manage state<br />
changes generated by each activity instance across<br />
an initiated process. This also allows the<br />
Execution Engine to initiate corrective actions<br />
based on process definitions and business rules.<br />
Figure 1 - Conceptual Model of <strong>BPM</strong><br />
User Environment<br />
Work Items<br />
& Work List<br />
Process Designer<br />
Defines<br />
Process Definition<br />
<strong>BPM</strong> System<br />
Generates<br />
Instantiates<br />
Invokes<br />
Execution Engine<br />
Updates<br />
Activity Monitor<br />
Accesses<br />
This may involve time limits defined within the<br />
process definition to trigger the prompting for<br />
user response, or process logic may require that<br />
routing be changed based on the state changed<br />
in an activity instance.<br />
The ability to manage state and process logic also<br />
allows the Execution Engine to facilitate hand-offs<br />
between process participants (person-to-person)<br />
and manage interactions between users and<br />
applications. For example, when a work item is<br />
delivered to the work list, the Execution Engine<br />
can pass on both the state from the previous<br />
activity and the description of what to do from<br />
the process definition (which may also be<br />
conditionally modified based on the state).<br />
Coordinating hand-offs between users<br />
distinguishes the role of the Execution Engine as a<br />
means of optimizing the performance of processes,<br />
rather than simply executing rules or code. This is<br />
accomplished in part by passing on Englishlanguage<br />
instructions and activity descriptions<br />
within a process object, as well as with manual<br />
Third Party<br />
Applications<br />
& Automated<br />
Activities<br />
Security &<br />
Directory<br />
Services<br />
Validates<br />
Persists<br />
Operational<br />
Data<br />
activities where written instructions<br />
are delivered through a work item.<br />
In this manner, the Execution Engine<br />
allows autonomous execution of<br />
individual activities, while maintaining<br />
the continuity and integrity of the<br />
executed process. While no company<br />
keeps its knowledge workers on a<br />
production line, it should still be<br />
evident how <strong>BPM</strong> enables more<br />
efficient utilization of human resources<br />
by facilitating the execution of work.<br />
Specifically, by bringing work directly<br />
to users with the process context and<br />
task information necessary to execute<br />
each step, rather than having them<br />
waste trying to figure out what to do,<br />
what they need and where to find it.<br />
This also illustrates another key benefit<br />
of <strong>BPM</strong> systems versus the alternative<br />
approaches of application integration<br />
and automation.<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Process Orchestration<br />
7<br />
By facilitating the execution of manual activities,<br />
the <strong>BPM</strong> system is not automating work (as parts<br />
of the process still consist of human work), but<br />
rather it is orchestrating the process.<br />
The Execution Engine manages the sequencing<br />
and distribution of activities, as well as parameters<br />
such as data variables captured or updated, time<br />
constraints on activities, and the state of activities.<br />
Yet the performance of work is left to human<br />
workers, not scripted into application code.<br />
This again presents a subtle yet significant<br />
difference that clearly illustrates the value of <strong>BPM</strong><br />
software. Just as manual activities can be defined<br />
and managed within a process without having to<br />
code every action, processes can be defined within<br />
a <strong>BPM</strong> system based on specific goals and<br />
outcomes without having to explicitly define<br />
every step. This presents the notion of process<br />
orchestration, which differentiates <strong>BPM</strong> from<br />
traditional workflow automation.<br />
Orchestration vs. Automation<br />
The basic notion of orchestration involves the<br />
development of executable processes as a set of<br />
loosely-coupled activities, rather than explicitly<br />
coded steps. Yet the concept of orchestration is<br />
rooted in the fundamental shift of application<br />
design towards the delivery of software as a<br />
service, evolving from the maturation of both J2EE<br />
and Web services. This shift has shaped both the<br />
philosophy and fundamental technologies behind<br />
nearly all software development today.<br />
A simple definition of an application is a set of<br />
activities or use-cases strung together for a<br />
specific purpose or function. The philosophy that<br />
governed application development until only<br />
recently was that of building an amalgamation of<br />
activities through which business and application<br />
logic are inseparable. As is vivid in virtually every<br />
enterprise today, the inevitable result is a rigid and<br />
virtually unmanageable morass of code.<br />
Certainly a better approach is to build as a<br />
collection atomic activities, connected and<br />
coordinated by a separate layer of business logic.<br />
This approach has slowly emerged through the<br />
evolution of N-tier application architectures,<br />
driven by the ability to leverage existing services<br />
from the platform and infrastructure. A necessary<br />
piece missing from component-based platforms<br />
such as J2EE and Microsoft (COM and .NET),<br />
however, is the independent process layer.<br />
Web Services and Process Orchestration<br />
Although componentization and its inherent<br />
benefits of software reuse has been common<br />
within the world of J2EE programming, the<br />
emergence of open standards for integration<br />
(most notably the Web services stack of SOAP,<br />
WSDL, XML and UDDI) presents a standard,<br />
application-independent means for components<br />
to be exposed as a library of invokable services.<br />
Connecting two points (i.e., reading into a single<br />
application from another) is not by itself<br />
revolutionary. What is, however, is building<br />
libraries of components into a vast network of<br />
distributed services. This is the concept of<br />
software virtualization, or what is increasingly<br />
referred to as a Service-Oriented Architecture<br />
(SOA).<br />
While most of the attention focused on SOA<br />
has been largely dominated by Web services,<br />
it is important to realize that these standards<br />
are merely one of the means to an end and not<br />
the end game itself. The true value of SOA comes<br />
from the ability to orchestrate these components<br />
across executable business processes.<br />
Bridging the Islands of Automation<br />
By definition, the use of Web services presumes<br />
that automation is already in place (i.e., Web<br />
services enables connectivity between automated<br />
activities), yet very often this exists as the<br />
proverbial "islands of automation" with no<br />
visibility between them. One system might handle<br />
the shipping documents, with another<br />
coordinating shipping schedules, and another<br />
tracking shipping status. Thus each system is<br />
responsible for a discrete function, yet lacks the<br />
ability to determine if or where a process may have<br />
broken down within any of the related but<br />
otherwise disconnected systems.<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Phases of Orchestration<br />
8<br />
Whether or not your business involves shipping<br />
products, this is nonetheless likely to be a familiar<br />
scenario for any firm that has invested in<br />
automation without orchestration. One approach<br />
to this problem would be to integrate these<br />
otherwise disparate systems with EAI. Yet this<br />
would not address the need for process<br />
coordination, would not help with handling<br />
exceptions, and would still come at a very high<br />
deployment cost. Exposing these application<br />
capabilities as Web services would offer visibility<br />
without the inherent rigidity of EAI, and thus over<br />
the long-term would be more cost effective to<br />
maintain. But Web services alone would do little to<br />
help coordinate processes across these systems.<br />
The First Phase of Orchestration<br />
Most <strong>BPM</strong> systems on the market today can<br />
“consume” Web services. In other words, when<br />
Web services are registered within a standard<br />
directory (UDDI) and wrapped with a standard set<br />
of descriptors (WSDL and XML) they can be<br />
invoked by a <strong>BPM</strong> system as an automated activity.<br />
Many <strong>BPM</strong> systems allow Web services to be<br />
“discovered” from within the process designer and<br />
added to the design palette, such that they can be<br />
added to the process definition without requiring<br />
any other formal integration effort.<br />
The standard Web services interfaces describe to<br />
the <strong>BPM</strong> system how to invoke the service and<br />
what data variables can be sent to and/or from the<br />
service. Depending on the complexity of the<br />
service, these data variables are either mapped<br />
within the process designer or automatically<br />
added to the process definition requiring only<br />
basic validation during the design process.<br />
This represents the significant first stage of<br />
moving from automation to orchestration, by<br />
combining process management with Web<br />
services. It allows for external applications and<br />
data to integrated into executable business<br />
processes with minimal programming effort<br />
compared to what would otherwise be required.<br />
It also leverages the inherent flexibility of Web<br />
services over other integration approaches. Since<br />
it is expressed as a Web service, the service<br />
component is self-describing and self-contained.<br />
Changes within the application (such as adding a<br />
new data table or moving up to a new system<br />
version) will be resolved through the Web services<br />
definition and not require a redesign of the<br />
process. Anyone who has dealt with other forms of<br />
EAI knows full well the problems involved with<br />
application changes breaking integration<br />
connections. In the context of live processes, these<br />
changes will bring work to a screeching halt.<br />
However the combination of Web services and<br />
process management also allows the ability to<br />
design processes based on specific goals and<br />
outcomes, without having to explicitly define every<br />
possible permutation or flow path. Just as with a<br />
manual activity, within an orchestrated process a<br />
step can be defined as "Check Shipment" or "Notify<br />
Receiver" (using the example earlier in this<br />
section) and as such invoke a Web service to<br />
retrieve shipping status or send out a notification<br />
based on a specific set of input variables. To do<br />
this within a traditionally automated process<br />
would require volumes of coding.<br />
The Next Phase of Orchestration<br />
Beyond consuming Web services, the next stage of<br />
orchestration is to use the <strong>BPM</strong> systems<br />
specifically to enable software virtualization.<br />
Although the Web services architecture is<br />
increasingly adopted by application developers<br />
such as SAP and PeopleSoft, as well as platform<br />
vendors such as IBM and Microsoft, the most likely<br />
scenario is that application capabilities desired are<br />
not exposed services and may not have the<br />
descriptive metadata required to easily access<br />
without integration.<br />
This presents two obvious options: using<br />
proprietary application adapters, or building<br />
proprietary integration points. Pursuing either<br />
option outside of a <strong>BPM</strong> system (i.e., for the<br />
purpose of accessing these within process<br />
definitions) is an expensive proposition in terms<br />
of either the cost of application adaptors or the<br />
cost of development time or both.<br />
Addressing this from within a <strong>BPM</strong> system offers<br />
two similar options, yet in most cases at a<br />
much lower price point. This also likely includes<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Orchestration & Virtualization<br />
9<br />
leverage of standard interfaces such as ODBC,<br />
COM/DCOM or J2EE interfaces such as JAAS, JTS,<br />
JDBC, and JNDI. But for proprietary systems other<br />
means of entry are required.<br />
Many <strong>BPM</strong> systems on the market today offer the<br />
option of a pre-integrated library of application<br />
adapters. These carry with them two important<br />
caveats:<br />
1) there is no such thing as a “universal<br />
adapter” as every application requires some<br />
modification of data structures; and<br />
2) adapters are typically designed for a specific<br />
version, which must be synchronized with the<br />
connected applications.<br />
What pre-integrated adapters do allow, however, is<br />
the ability to define integration points within the<br />
process designer and enable easier access to<br />
applications than would be available with<br />
proprietary EAI. Once integrated, this allows<br />
application services to be registered once and<br />
reused throughout process definitions.<br />
The second approach is to enable integration<br />
syntax directly within the process designer. <strong>BPM</strong><br />
systems which offer this capability typically<br />
delineate separate levels of abstraction --- one<br />
which defines business and flow logic, and another<br />
which defines integration logic. These also allow<br />
the registry of application services as individual<br />
components, enabling them to be included within<br />
the designed palette and reused throughout the<br />
process definition.<br />
Certainly, neither approach offers<br />
a “magic bullet” to application integration.<br />
Any integration effort<br />
will require significant development time<br />
and effort to introduce external<br />
application services to process<br />
management. What these<br />
alternatives do offer over other<br />
approaches, however, is specifically<br />
that -- allowing application services<br />
to be introduced to process<br />
management rather than trying to<br />
manage processes around<br />
application functionality.<br />
Figure 2 - An Automated Process<br />
Figure 2 above illustrates a typical<br />
automated process, where each step is<br />
defined explicitly in terms of all possible<br />
permutations and outcomes.<br />
Figure 3 below illustrates the same<br />
process based on an orchestration<br />
strategy, where steps are defined as<br />
autonomous activities or invoked<br />
services. The same level of control flow<br />
is enabled in both examples, however,<br />
the orchestrated process offers a far<br />
more streamlined design and fewer<br />
points of failure (by defining steps in<br />
terms of outcome rather than scripted<br />
rules).<br />
Figure 3 - An Orchestrated Process<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Orchestration Summary<br />
10<br />
Process Orchestration Myths and Realities<br />
The role of orchestration in process management<br />
offers a vivid illustration of evolutionary advances<br />
of current <strong>BPM</strong> software over earlier approaches to<br />
process automation. It should be noted that<br />
orchestration is not a “quick fix” for managing<br />
processes without proper analysis of business<br />
logic.<br />
What an orchestration-based approach does offer<br />
is the ability to manage processes of greater<br />
complexity with far more efficiency than is<br />
otherwise possible with alternative approaches.<br />
The key to this is a modular approach to managing<br />
business rules, relationships, and activities.<br />
Within an automation paradigm, processes are<br />
defined “end-to-end” with all possible paths (or<br />
more commonly a single path) pre-determined.<br />
Thus ‘Step #5’ always follows ‘Step #4’ and precedes<br />
‘Step #6’ even if different instances of an otherwise<br />
standard process may require a different sequence.<br />
Orchestration allows for the sequencing of steps to<br />
be determined during the “run-time” instance of a<br />
process, with paths determined by evolving context<br />
resulting from each new step. Thus the potential<br />
number of paths and outcomes may otherwise be<br />
too complex to define in terms of pre-determined<br />
“If-Then-Else” rules, but may be easily resolved<br />
through human interaction and decision-making.<br />
This highlights the key architectural difference<br />
between automation and orchestration. Given the<br />
inherent complexity and constant changes within<br />
any “real world” business environment, effectively<br />
managing processes requires the agility to shift<br />
with changes in context, rather than always being<br />
bound to the same scripted flow. This requires the<br />
unique ability to define processes as a set of<br />
atomic, goal-based activities with the enforcement<br />
of basic parameters (e.g., time limits, data<br />
variables), while separating the execution logic<br />
activities from the higher-level process definition.<br />
As discussed throughout this section, process<br />
orchestration presents the intersection of process<br />
management and Web services. To be clear,<br />
however, process orchestration should not be<br />
confused with other emerging approaches of Web<br />
services orchestration and choreography. Process<br />
orchestration is not limited to invoking software,<br />
but rather represents a shift from task-based to<br />
goal-oriented process definition. Web services<br />
and other forms of software automation are<br />
utilized through process orchestration, yet not to<br />
the exclusion of manual, human-driven activities.<br />
When examining the process management<br />
software space, differentiation should be made<br />
between automation and orchestration, as well as<br />
between service-oriented processes versus contextdriven<br />
process management focused on<br />
coordinating both manual and automated<br />
activities. <strong>BPM</strong> software products overlap one<br />
or more of the categories defined below.<br />
Process Management<br />
Software Landscape<br />
Orchestration-Centric<br />
Service-Oriented<br />
Supports processes<br />
involving the coordination<br />
of external application<br />
services. Enables both<br />
consuming and generation/<br />
publishing of services from<br />
external applications.<br />
Provides fine grain control<br />
over invoked services.<br />
Workflow-Driven<br />
Supports processes with<br />
a discrete number of<br />
predetermined steps,<br />
paths, and outcomes.<br />
Supports invocation of<br />
external services through<br />
data exchange only.<br />
Context-Driven<br />
Supports process flow paths<br />
dependent on the outcome<br />
of previous steps. Enables<br />
orchestration processes<br />
where all possible path<br />
permutations and process<br />
outcomes cannot be<br />
pre-defined.<br />
Rule-Driven<br />
Supports the ability to<br />
define and resolve<br />
discrete business rules.<br />
Rules engines use<br />
If-Then-Else definitions<br />
to resolve process<br />
conditions and events.<br />
Automation-Centric<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Components of <strong>BPM</strong><br />
11<br />
Whole-Product Requirements:<br />
Market Expectations<br />
In an effort to assess the market’s priorities for<br />
whole-product requirements, respondents were<br />
asked to identify which components they believe<br />
should be either self-contained (i.e., proprietary),<br />
pre-integrated (i.e., third-party component<br />
integrated by vendor) or independent (i.e.,<br />
integration left to deploying organization).<br />
As stated earlier, the combination of these<br />
components represents the basic configuration<br />
of any viable <strong>BPM</strong> solution (with the exception of<br />
the App server). The objective with this research,<br />
however, is to determine the market’s expectation<br />
for best-of-breed software options for <strong>BPM</strong>. Not<br />
surprisingly, two-thirds of respondents view<br />
<strong>BPM</strong> as necessarily independent of the app server<br />
platform (counter to positioning by vendors<br />
such as IBM, Oracle, and BEA Systems).<br />
What is notable among these responses is the<br />
high ranking of business rules engines as a<br />
core component. This runs counter to the<br />
fact that rules engines have been largely<br />
abstracted from application software “stacks”<br />
and are today widely available as independent<br />
services. The likely explanation for this is<br />
the market’s expectations for the ability<br />
to define business rules within<br />
process definitions, using the<br />
process designer.<br />
Many vendors leverage separate rules engines,<br />
rather than seeking to replace already deployed or<br />
otherwise off-the-shelf options available on the<br />
market today.<br />
Combining functions of business rules and<br />
process execution, as well as activity monitoring,<br />
presents the capabilities found in the sub-segment<br />
of “<strong>BPM</strong> engines” on the market today. These<br />
represent an emerging class of software<br />
applications focused specifically on introducing<br />
process execution capabilities to existing<br />
applications and new development initiatives.<br />
Typically independent <strong>BPM</strong> engines work across<br />
multiple deployment environments. This also<br />
means that no deployment environment (i.e., app<br />
server) is provided, and thus anticipates that target<br />
applications will have the necessary deployment<br />
infrastructure in place. Similarly, in contrast with<br />
other offerings that base differentiation on the<br />
completeness of built capabilities, independent<br />
<strong>BPM</strong> engines focus foremost on lightweight<br />
deployment overhead and are designed to leverage<br />
existing infrastructure wherever possible. Through<br />
the use of component-based architectures, many<br />
<strong>BPM</strong> solutions also offer execution engines alone<br />
as OEM offerings for other software vendors.<br />
Necessary Components of<br />
Any <strong>BPM</strong> Solution (ranking by respondents)<br />
Should Be a<br />
Core Component<br />
of Any <strong>BPM</strong> Solution<br />
Vendor Should<br />
Pre-Integrate<br />
Best-of-Breed Alternatives<br />
Definitely Should<br />
Be Indepdent<br />
No Answer<br />
Given<br />
Business Rules Engine 67% 26% 7%<br />
Execution Engine<br />
(manage process instances)<br />
Process Activity Monitor<br />
Directory Services (Define and Manage<br />
Users, Roles, Teams, etc)<br />
Analytical Reporting<br />
& Performance Metrics<br />
Integration Platform<br />
Work Portal<br />
(access <strong>BPM</strong> work list)<br />
Application Server<br />
64% 27% 7% 3%<br />
60% 33% 7% 0%<br />
49% 39% 12% 0%<br />
45% 41% 12% 1%<br />
45% 41% 12% 2%<br />
44% 42% 13% 2%<br />
31% 46% 22% 1%<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
What’s Missing From Current Offerings<br />
12<br />
Market’s Perspective:<br />
As shown at the bottom-right chart, respondents<br />
were asked to indicate from a provided list of<br />
capabilities which of those were perceived to be<br />
missing from current <strong>BPM</strong> solutions. This was a<br />
“check all that apply” choice and as such the most<br />
relevant take-away from this is not individual<br />
numbers but the contrast between each category.<br />
The fact that process model standards featured so<br />
prominently on this (cited by nearly half of all<br />
survey respondents) indicates this to be a<br />
significant issue among <strong>BPM</strong> users and evaluators.<br />
The next two highest ranking responses are related<br />
to process modeling if not interchange standards<br />
directly. Combined these reinforce the importance<br />
of the development environment as well as the use<br />
of <strong>BPM</strong> as tool for enabling process improvement.<br />
This is consistent with the results from a related<br />
question (illustrated below) where respondents<br />
were asked to identify their single greatest priority<br />
for investing <strong>BPM</strong>.<br />
Enterprise-wide Redesign<br />
of Business Processes<br />
Data-Level<br />
Application Integration<br />
Rule-based or Event-Drivern<br />
Document Routing<br />
Enforce Business Rules<br />
With Trading Partners<br />
Define & Map Business<br />
Processes<br />
Monitor Staff Performance<br />
& Activities<br />
Ensure Integrity of<br />
Internet Transactions<br />
Extend Existing Apps<br />
11.0%<br />
18.9%<br />
9.9%<br />
13.9%<br />
9.3%<br />
7.4%<br />
8.8%<br />
8.2%<br />
6.5%<br />
4.1%<br />
4.5%<br />
5.7%<br />
4.0%<br />
4.1%<br />
46.0%<br />
37.7%<br />
2003 Survey<br />
2001 Survey<br />
0% 10% 20% 30% 40% 50%<br />
Respondents were asked to identify<br />
their Single Greatest Priority for <strong>BPM</strong><br />
deployments from the list shown above.<br />
Enterprise-wide process redesign was<br />
favored nearly 5-to-1 over integration or<br />
other choices provided, representing a<br />
significant shift over responses in 2001.<br />
Reality:<br />
Enabling the interchange of process models has<br />
been a priority for workflow and (later) <strong>BPM</strong><br />
vendors since the beginning of this industry<br />
segment. This was one of the initial goals of the<br />
Workflow Management Coalition (WfMC) with a<br />
specification known as “Interface 1” and later the<br />
Workflow Process Definition Language (<strong>WP</strong>DL).<br />
Despite some proof-of-concept demonstrations,<br />
neither standard has featured prominently in <strong>BPM</strong><br />
deployments or offerings.<br />
What has shifted the landscape for interchangeable<br />
process models, however, is the use of XML to<br />
represent process definitions. This has enabled a<br />
number of proprietary interfaces between process<br />
modeling tools and process execution engines, as<br />
well as XML-based standards such as the WfMC’s<br />
XML Process Definition Language (XPDL).<br />
The second wave of process standards was<br />
initiated first by <strong>BPM</strong>I.org with the development of<br />
Business Process Modeling Notation (<strong>BPM</strong>N) for<br />
model definition and Business Process<br />
Management Language (<strong>BPM</strong>L) as declarative<br />
language for process execution. These are<br />
discussed in detail within the section on standards<br />
at the end of this report.<br />
Features Missing From <strong>BPM</strong> Solutions<br />
(percent cited from all respondents)<br />
Standardized Interchange<br />
of Process Models<br />
Business Performance<br />
Management<br />
Richer Graphical<br />
Monitoring & Simulation<br />
Orchestration & Negotiation<br />
Quality of Service<br />
Metrics & Monitoring<br />
Analytical Reporting<br />
& Monitoring Capabilities<br />
Transaction Verification<br />
& Delivery Guarantees<br />
Usage Metering & Billing<br />
34.0%<br />
33.0%<br />
28.0%<br />
27.0%<br />
26.0%<br />
22.0%<br />
18.0%<br />
44.0%<br />
©2003 Delphi Group<br />
0% 10% 20% 30% 40% 50%<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Product Selection Criteria<br />
13<br />
Product Selection Criteria:<br />
How Market Evaluates <strong>BPM</strong> Solutions<br />
Similar to the exercise to identify market<br />
perceptions, respondents were asked to rank the<br />
level of priority for the issues and functions shown<br />
below with regards to product selection criteria.<br />
Of the fifteen points of consideration, responses<br />
were categorized in terms of integration-specific<br />
criteria (see page 16) and overall functionality<br />
(below).<br />
Among issues of overall functionality, those with<br />
highest negative responses (i.e., instances where<br />
the lowest priority is placed) relate to platform<br />
choices, which is understandable given the<br />
inherent polarity of these choices and the fact that<br />
a certain percentage of the population will always<br />
pick one platform over another.<br />
The area of criteria associated with the greatest<br />
priority, however, should not be surprising to<br />
anyone who has gone through a product selection<br />
process, yet may otherwise be dismissed by some<br />
as trivial. The criterion in question is the role of<br />
process modeling environments, which is often<br />
dismissed by industry pundits as immaterial,<br />
compared with issues of server performance and<br />
other more technically oriented matters. Despite<br />
this, Delphi’s field experience has consistently<br />
concurred with the findings of this piece of<br />
research, showing that <strong>BPM</strong> software evaluators<br />
very often place a top priority on process<br />
modeling environments, a factor often<br />
underestimated by software suppliers.<br />
Aligned with process modeling priority is the<br />
need to leverage existing resources and skill sets<br />
(ranked nearly as high). This ties into the fact<br />
that most <strong>BPM</strong> deployments involve the<br />
development of an internal process team and<br />
competency. These teams are typically not lead<br />
by IT (a fact reinforced by findings shown later in<br />
this report), but rather are made up largely of<br />
business process owners and users. For this<br />
reason, process designers must be able to<br />
accommodate non-technical users.<br />
The third highest priority is access to integrated<br />
analytical capabilities and business performance<br />
monitoring, which also ranked as a close third<br />
within whole-product requirements. Again, this<br />
reinforces the notion of <strong>BPM</strong> as a means of<br />
enabling continuous process improvement.<br />
Development trends among <strong>BPM</strong> vendors reflect<br />
this requirement, with an increasing number<br />
including OLAP capabilities and other robust<br />
report functionality within core product offerings.<br />
Overall Functional Priorities Driving<br />
Product Selection Criteria<br />
Graphical Mapping & Monitoring<br />
of Business Process<br />
Leverage of Existing<br />
Resources & Skill Sets<br />
Integrated Analytics Engine, or<br />
Business Performance Monitoring<br />
Support for J2EE App Servers<br />
& Related Standards<br />
Independent Validation of<br />
Project & Software ROI<br />
Acccess to a Published Standard<br />
for Process Modeling & Definition<br />
Support for Microsoft<br />
Infrastructure & Standards<br />
©2003 Delphi Group<br />
Little to No<br />
Importance<br />
Moderately<br />
Important<br />
Very<br />
Important<br />
Single<br />
Greatest<br />
Priority<br />
8% 29% 53% 9%<br />
8% 33% 53% 6%<br />
11% 37% 46% 6%<br />
21% 29% 45% 5%<br />
19% 33% 42% 7%<br />
17% 36% 40% 7%<br />
30% 23% 40% 7%<br />
Direction of Increasing Priority<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Defining Business Logic<br />
14<br />
Business Software for a<br />
Business Audience<br />
As discussed on the previous page,<br />
<strong>BPM</strong> deployments are led<br />
predominantly by line-of-business<br />
managers and business process owners.<br />
This is not to suggest that <strong>BPM</strong> does not<br />
require the involvement of IT and other<br />
technical resources. IT will be required<br />
for <strong>BPM</strong> just as with any other major<br />
software deployment. What is unique<br />
about <strong>BPM</strong>, however, is the much larger<br />
role played by traditional business<br />
(i.e., non- technical) personnel.<br />
The two most significant components of<br />
a <strong>BPM</strong> deployment are defining business logic and<br />
identifying integration points. This requires the<br />
ability to express <strong>BPM</strong> deployment requirements<br />
in non-technical terms, including process flows as<br />
well as complex business rules and relationships.<br />
This requirement highlights the importance of the<br />
process designer and development environment,<br />
which holds the potential to be the greatest point<br />
of failure in any <strong>BPM</strong> deployment.<br />
If processes are not properly articulated and<br />
validated in the design phase, they will of course<br />
fail upon deployment. Treating end users as the<br />
test bed for processes not properly validated will<br />
result in significant culture resistance and<br />
reluctance to cooperate with further iterations.<br />
Senior Management, Not CIO<br />
Individual Process Owners<br />
or Line-of-Business Managers<br />
©2003 Delphi Group<br />
Individual Process Owners<br />
or Line-of-Business Managers<br />
Enterprise Architect<br />
E-Business Leader<br />
Other Business Analyst(s)<br />
Outside Consultants<br />
Other (please specify)<br />
Internal Programmers<br />
©2003 Delphi Group<br />
Project Sponsor for <strong>BPM</strong> Investments<br />
CIO (or equivalent)<br />
Other<br />
Marketing<br />
E-Business Leader<br />
2.6%<br />
2.1%<br />
7.2%<br />
11.6%<br />
30.0%<br />
0% 10% 20% 30% 40% 50%<br />
46.5%<br />
Responsibility for Defining<br />
Business Rules & Process Logic<br />
2%<br />
2%<br />
4%<br />
9%<br />
12%<br />
17%<br />
It is for these reasons that proper definition of<br />
process logic is necessary for the success of any<br />
<strong>BPM</strong> deployment, and why input from business<br />
process owners is so crucial.<br />
As stated earlier, most <strong>BPM</strong> deployments involve<br />
the development of cross-functional (i.e., IT and<br />
business) process teams. The lingua franca for<br />
these teams may initially be flow charting tools,<br />
but at some point (ideally earlier than later) this<br />
needs to switch to the actual process design<br />
environment used to create process definitions.<br />
The later in the deployment process this segue<br />
occurs, the greater the probability for the<br />
misinterpretation of business requirements as<br />
they are translated into process definitions.<br />
55%<br />
This has led some firms to use<br />
modeling methodologies such as UML,<br />
that are designed for enterprise and<br />
application modeling. The caveat with<br />
methodologies such as UML, or even<br />
process-specific methods such as IDEF,<br />
is that these do not allow for fine grain<br />
articulation of product-specific process<br />
definitions, and thus run a similar risk<br />
of misinterpreting business<br />
requirements. A better approach is to<br />
select a <strong>BPM</strong> solution that supports<br />
business-level process modeling within<br />
the same environment as more granular<br />
integration and application syntax.<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
<strong>BPM</strong> Benefits<br />
15<br />
What’s in it for IT?<br />
Respondents were asked to identify<br />
(separately) the anticipated IT-specific<br />
benefits and overall functional benefits<br />
anticipated through deploying <strong>BPM</strong> software.<br />
The clear winner among IT benefits is the<br />
ability to integrate internal applications.<br />
As this admittedly presents only a limited<br />
perspective (respondents were forced to pick<br />
one answer from limited options) further<br />
definition of integration priorities are<br />
provided on the next page.<br />
What these responses do indicate more than<br />
anything else, however, is the education<br />
challenge facing <strong>BPM</strong> vendors. Integration<br />
ranked fairly low among top priorities as<br />
shown earlier in this report. Yet a challenge the<br />
<strong>BPM</strong> market has faced is lack of recognition for<br />
other IT-related benefits than integration. These<br />
include easier (and cheaper) maintenance of<br />
enterprise software, through the use of<br />
orchestration capabilities (versus custom-coding)<br />
to expose application services. As well as the<br />
ability to develop new capabilities without the<br />
comparatively higher expense involved with<br />
building these within existing application<br />
environments.<br />
As many CIO’s budgets are today consumed<br />
largely by application integration and<br />
maintenance costs, <strong>BPM</strong> offers a<br />
high-leverage opportunity for<br />
addressing new problems such as<br />
Sarbanes-Oxley compliance (which<br />
now puts CIOs on the line for<br />
accounting practices). From a<br />
business user perspective, the<br />
greatest benefit of <strong>BPM</strong> is seen as<br />
the ability to manage business rules<br />
and process definitions without<br />
having to rely on IT for every<br />
required change. This too should be<br />
viewed by IT as an inherent benefit,<br />
as well as a means for enabling<br />
orchestration over automation (i.e.,<br />
leveraging existing automation<br />
within applications).<br />
Change Business & Processs Rules<br />
Within Enterprise Software<br />
Without IT Intervention<br />
Manage Exceptions<br />
Within Automated Processes<br />
Ability To Visualize, Simulate,<br />
& Trouble-Shoot<br />
Business Processes<br />
Automate Repetitive Tasks<br />
& Accelerate Process Cycle Times<br />
Single Greatest Functional<br />
Advantage Anticipated from <strong>BPM</strong><br />
Monitor Personnel<br />
& Process Performance<br />
©2003 Delphi Group<br />
©2003 Delphi Group<br />
Single Greatest IT-Specific Benefit<br />
Anticipated from <strong>BPM</strong><br />
Cost-Effective Integration<br />
of Internal Applications<br />
Accelerate Deployment<br />
of New Applications<br />
Reduce Total Cost of Ownership<br />
of Existing Application<br />
Integration of Applications<br />
Outside of The Firewall<br />
Add "State" to<br />
Stateless Applications<br />
Ability to Reuse Software Code<br />
Other<br />
Other<br />
2%<br />
4%<br />
8%<br />
11%<br />
10%<br />
10%<br />
16%<br />
0% 10% 20% 30% 40% 50%<br />
15%<br />
13%<br />
17%<br />
41%<br />
Respondents were asked to pick the<br />
single greatest advantage from two lists<br />
of IT-related and general business<br />
functional advantages. While cost-effective<br />
integration is clearly favored among<br />
IT benefits, business benefits are much<br />
more evenly split.<br />
24%<br />
28%<br />
0% 5% 10% 15% 20% 25% 30%<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Integration Priorities<br />
16<br />
Integration Priorities:<br />
The Market’s Perspective<br />
When asked to prioritize integration-specific<br />
product selection criteria, respondents indicated a<br />
bias favoring cross-application process integration.<br />
Within the language of the survey, the word<br />
“orchestration” was not used explicitly, as this is a<br />
relatively new term which is open to multiple<br />
interpretations. Yet the desire for orchestration as<br />
described and defined in this report is clearly<br />
favored over simply enabling data-level integration<br />
(both in the results shown below and indicated<br />
earlier).<br />
What is equally clear, is that integration in general<br />
remains a significant priority in most <strong>BPM</strong><br />
deployments. As is illustrated in several different<br />
charts and findings, integration only falls when<br />
respondents are asked to identify top drivers of<br />
<strong>BPM</strong> initiatives (i.e., where the choice of<br />
integration is mutually exclusive of other choices).<br />
This illustrates a central message of this report,<br />
that <strong>BPM</strong> is not about enabling point-to-point<br />
connections between applications, but rather the<br />
ability to define and orchestrate business<br />
processes that take advantage of capabilities and<br />
existing automation within multiple applications.<br />
Where respondents appear equally split or<br />
otherwise indifferent within the findings<br />
illustrated below is when it comes to whether or<br />
not <strong>BPM</strong> should be a component of integration<br />
Connecting Otherwise Disparate Processes<br />
Across Multiple Software Applications<br />
software or offered independent of any EAI or<br />
integration platform. This is a subtle distinction<br />
in the context of a high-level assessment of <strong>BPM</strong>.<br />
Yet for practical purposes, <strong>BPM</strong> offered as a<br />
component of EAI will not allow for necessary<br />
flexibility to enable process orchestration.<br />
Architecturally, <strong>BPM</strong> needs to be an independent<br />
layer which takes advantage of integration<br />
capabilities, either internally or in partnership<br />
with third-party EAI offerings. Otherwise, the<br />
ability for <strong>BPM</strong> services to be invoked by both<br />
external applications and user environments<br />
(work lists) will be compromised.<br />
Most <strong>BPM</strong> offerings on the market today present<br />
some level of integration capability, with varying<br />
levels and approaches. For <strong>BPM</strong> initiatives where<br />
external applications play a large role at multiple<br />
points across a process, the ability to define<br />
invocation capabilities within process definitions<br />
will play a large role in the resulting deployment’s<br />
agility and performance. For processes that are<br />
largely collaborative or “people-centric” in design,<br />
the ability to read data from external applications<br />
may be sufficient. For enabling orchestration<br />
across multiple application services, however, the<br />
<strong>BPM</strong> solution used must allow for fine grain<br />
articulation of integration and invocation syntax.<br />
Integration-Specific Priorities<br />
Driving Product Selection Criteria<br />
Little to No<br />
Importance<br />
Moderately<br />
Important<br />
Very<br />
Important<br />
Single<br />
Greatest<br />
Priority<br />
6% 24% 57% 13%<br />
Integrating <strong>BPM</strong> Within<br />
Existing Applications & Initiatives<br />
Ability to Access Outside<br />
Data Within the <strong>BPM</strong> Environment<br />
Direct Access to API<br />
Set of <strong>BPM</strong> Engine<br />
<strong>BPM</strong> as a Component of<br />
or Integrated With EAI<br />
Independent of Any Single Apps Server,<br />
EAI Tool, or Enterprise Application<br />
8% 23% 57% 13%<br />
8% 26% 57% 9%<br />
13% 36% 45% 6%<br />
20% 35% 40% 5%<br />
22% 36% 37% 5%<br />
Transaction Processing<br />
& Load-Balancing<br />
19% 42% 37% 3%<br />
©2003 Delphi Group Direction of Increasing Priority<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Requirements for Software Suppliers<br />
17<br />
Who Gets The Deal?<br />
The market for <strong>BPM</strong> software remains price<br />
sensitive, with the most common answer by<br />
respondents that vendor selection will be made<br />
according to the lowest price. This may be<br />
disheartening to most <strong>BPM</strong> vendors, yet it remains<br />
a reality for most software segments as<br />
IT budgets continue to shrink relative to available<br />
dollars (not otherwise earmarked for maintenance<br />
and integration). This number may be understated<br />
due to best intentions by some respondents,<br />
who may change their tune when ultimately forced<br />
to justify their investments. Thus the percent of<br />
purchases made based on the lowest bid may<br />
actually be larger than is indicated here.<br />
One significant shift seen in the 2003 results over<br />
2001, however, is the favoring of large brand<br />
vendors. This too reflects macro trends across<br />
the software industry, with many smaller vendors<br />
complaining of what felt to be the unfair scrutiny<br />
of their size and viability. Yet for the <strong>BPM</strong> market<br />
it is too soon for a “Big 3” set to dominate.<br />
Innovation traditionally flows from upstarts, not<br />
incumbents. This has been no different for the<br />
<strong>BPM</strong> software industry, where large platform<br />
vendors such as Microsoft, IBM, and Oracle (e.g.,<br />
the traditional software Big 3) have remained<br />
notably deficient in process management<br />
capabilities (in particular relative to the offerings<br />
of much smaller vendors).<br />
The lack of presence by large<br />
platform vendors reflects the<br />
generally nascent state of the <strong>BPM</strong><br />
sector (a market arguably only a few<br />
years old) and the lack of critical<br />
mass among large system buyers<br />
(see pages 19-20 for the size of total<br />
and individual spending). One factor<br />
already shaping the competitive<br />
landscape, however, is the emergence<br />
of standards driven by the larger<br />
platform players.<br />
Most notable is BPEL or Business Process Execution<br />
Language, submitted to the standards body OASIS<br />
by vendors including Microsoft, IBM, BEA Systems,<br />
and SAP. Due to its backing by these large vendors,<br />
as well as its growing support by “pure play” <strong>BPM</strong><br />
vendors, BPEL is expected by many to emerge as<br />
the dominant <strong>BPM</strong> standard. As an adopted<br />
standard, BPEL would allow a single process<br />
definition to run on multiple execution engines, as<br />
well as to exchange process objects between live<br />
processes running on different systems.<br />
If BPEL or another standard does mature to allow<br />
true interchangeability between <strong>BPM</strong> systems, this<br />
will put pressure on all <strong>BPM</strong> players to<br />
differentiate based on valued-added capabilities.<br />
Similar to the role that J2EE played on the until<br />
recently proprietary app server market, a single<br />
<strong>BPM</strong> standard should foster innovation by<br />
removing the threat to software buyers of locking<br />
into proprietary investments. If in this way<br />
competitive pressure (vis-a-vis buying criteria)<br />
shifts from company size to price and<br />
functionality, the results will be a greater number<br />
of affordable options for <strong>BPM</strong> buyers.<br />
Platform vendors have the opportunity to<br />
undercut smaller competitors by subsidizing the<br />
cost of <strong>BPM</strong> software. But opportunities remain for<br />
smaller vendors to differentiate on the basis of<br />
lower overall cost of ownership, with products that<br />
are easier and cheaper to deploy and maintain (see<br />
page 20 for a break out of the total cost of <strong>BPM</strong>).<br />
Financial Criteria for <strong>BPM</strong> Software Suppliers<br />
Will Work With Whoever Provides<br />
the Best Combination Of Price & Service<br />
Will Prioritize Selection Criteria<br />
According to Product<br />
& Organizational Capabilities<br />
Only Vendors With<br />
Dominant Brand Name<br />
Only Vendors With<br />
There is an Existing<br />
Commerial Relationship<br />
Only Publicly-Traded Vendors<br />
2%<br />
3%<br />
12%<br />
12%<br />
17%<br />
24%<br />
23%<br />
32%<br />
2003 Survey<br />
2001 Survey<br />
38%<br />
36%<br />
©2003 Delphi Group<br />
0% 10% 20% 30% 40%<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Current State of <strong>BPM</strong> Deployments<br />
18<br />
The Market Comes of Age --<br />
But a Business Case Still Must be Made<br />
While still in an early stage, the <strong>BPM</strong> market<br />
appears to be close to reaching critical mass, with<br />
the number of early adopter deployments nearly<br />
doubling since the 2001 survey (indicated by 20%<br />
of respondents indicating they are using <strong>BPM</strong><br />
already). The high number of firms in the early<br />
stage of evaluation (nearly half of all respondents)<br />
indicates that the market is on the cusp of a break<br />
out. If buyers move as indicated below, 75% of all<br />
firms responding to this survey will have invested<br />
in <strong>BPM</strong> inside of the next three years.<br />
The single greatest factor suppressing market<br />
expansion today is the lack of clearly defined<br />
business case. Combined with the lack of project<br />
sponsors (a closely related issue) the need to make<br />
the case for <strong>BPM</strong> investments has held back more<br />
than 60% of firms who have not yet invested. This<br />
illustrates the education challenge facing the<br />
supply-side of the <strong>BPM</strong> market. It is of greater<br />
importance today than price or functionality.<br />
<strong>BPM</strong> vendors have the onus of proving the<br />
business case for any investment regardless of<br />
price. An effective vehicle for this is the delivery of<br />
packaged solutions able to demonstrate very quick<br />
results, such as Sarbanes-Oxley or USA PATRIOT<br />
Act compliance or domain-specific solutions such<br />
as those for telecom provisioning . These are<br />
focused apps built on top of a core <strong>BPM</strong> platform,<br />
offering near turn-key deployment now, with a<br />
defined path for later expanding into other areas.<br />
Investment Timing for Firms Without<br />
Current Deployments or Initiatives<br />
40%<br />
34%<br />
Using <strong>BPM</strong><br />
Software Already<br />
State of <strong>BPM</strong> Deployments<br />
Final Stages<br />
of Deployment<br />
Early Stage<br />
of Evaluation<br />
No Plans<br />
for <strong>BPM</strong><br />
No Business<br />
Case<br />
No Project<br />
Sponsor<br />
9%<br />
4%<br />
12%<br />
20%<br />
23%<br />
29%<br />
0% 10% 20% 30% 40% 50% 60%<br />
©2003 Delphi Group<br />
Reasons Cited for<br />
Not Investing in <strong>BPM</strong><br />
28.0%<br />
24.0%<br />
28.0%<br />
2003 Survey<br />
2001 Survey<br />
Respondents were asked to identify their<br />
current state of <strong>BPM</strong> deployments, and<br />
where none were planned or in place,<br />
the single greatest reason for this.<br />
Findings were largely consistent<br />
year-over-year, with the most dramatic<br />
changes relative to firms who have<br />
invested since the 2001 survey, and the<br />
growing need for a business case<br />
among those who haven’t.<br />
48%<br />
55%<br />
36.7%<br />
Will Use Existing<br />
Apps/Platform<br />
17.6%<br />
18.3%<br />
9%<br />
< 6<br />
Months<br />
7-12<br />
Months<br />
2-3<br />
Years<br />
10%<br />
4-5<br />
Years<br />
1% 6%<br />
> 5<br />
Years<br />
Never<br />
Vendors Unable<br />
to Meet Needs<br />
Other<br />
14.9%<br />
9.7%<br />
6.8%<br />
16.1%<br />
2003 Survey<br />
2001 Survey<br />
0% 10% 20% 30% 40% 50%<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Investment Size & Pricing Models<br />
19<br />
How Big a Deal?<br />
Another sign of market maturity is the shift<br />
in anticipated spending reported in the “less than<br />
$100,000” range to anticipated spending between<br />
$1 million and $5 million. An investment of less<br />
than $100,000 over a three year period will<br />
certainly pay for a pilot, but not much more than<br />
a small deployment. So the decline in category is<br />
a positive sign for the market overall.<br />
Investment plans have remained relatively<br />
consistent, with the subtle shifts favoring larger<br />
transaction sizes. This is a forward-moving trend,<br />
and is consistent with what should be seen with<br />
any market maturity cycle. Where changes are<br />
most pronounced, however, is in relation to<br />
anticipated pricing models. The percent of<br />
respondents whose preferred pricing model is<br />
by the CPU more than doubled over 2001 findings.<br />
This trend is consistent with the direction of most<br />
vendors, particularly with architectures based on<br />
J2EE. Yet those citing preference for pricing per<br />
user also increased by more than 60% since 2001.<br />
Total <strong>BPM</strong> Software-Only Spending<br />
Anticipated Over the Next Three Years<br />
Nothing<br />
< $100,000<br />
$101,000 -<br />
250,000<br />
$251,000 -<br />
500,000<br />
$501,000 -<br />
1,000,000<br />
$1,001,000 -<br />
2,500,000<br />
$2,500,000 -<br />
5,000,000<br />
> $5,000,000<br />
15.7%<br />
15.4%<br />
20.9%<br />
19.7%<br />
11.3%<br />
10.3%<br />
9.6%<br />
12.0%<br />
5.2%<br />
2.6%<br />
5.2%<br />
0.9%<br />
2.0%<br />
5.1%<br />
30.1%<br />
34.2%<br />
2003 Survey<br />
2001 Survey<br />
0% 10% 20% 30% 40% 50%<br />
©2003 Delphi Group<br />
These price increases are at the expense of fixedprice<br />
and subscription based pricing (including<br />
SLAs). This trend may reverse or increase, based<br />
in the effect of new accounting regulations<br />
(Sarbanes-Oxley most notably) that alter the<br />
manner in software and other expenses must be<br />
amortized and recognized. At this point in time<br />
it is our expectation that subscription pricing<br />
(e.g., delivery of software as a service) will in fact<br />
increase in popularity as a result of these<br />
regulations.<br />
Single, fixed price<br />
for development environment<br />
Price per CPU<br />
Service Level Agreement<br />
Price per user<br />
Subscription fee based<br />
on processing volume and usage<br />
Price per process managed<br />
Preferred Pricing Model<br />
for <strong>BPM</strong> Investments<br />
10.2%<br />
22.0%<br />
27.1%<br />
21.4%<br />
20.0%<br />
23.7%<br />
19.4%<br />
11.9%<br />
12.5%<br />
2003 Survey<br />
17.8%<br />
2001 Survey<br />
4.6%<br />
3.4%<br />
Trends in transaction size indicate market<br />
growth over 2001 survey findings. Within the<br />
2003 survey, almost 90% of respondents cited<br />
<strong>BPM</strong> investments as either generating profits or<br />
at least netting out with expenses. This indicates<br />
expectations for positive ROI on <strong>BPM</strong>, but is also<br />
consistent with an expectation for deploying<br />
<strong>BPM</strong> as part of a for-profit or cost-cutting<br />
initiative, such as Business Process Outsourcing.<br />
Financial Role for <strong>BPM</strong><br />
Deployments<br />
Cost-Neutral<br />
(42%)<br />
Cost Center<br />
(19%)<br />
Profit Center<br />
(39%)<br />
©2003 Delphi Group<br />
0% 10% 20% 30% 40% 50%<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
<strong>BPM</strong> Market Size & Momentum<br />
20<br />
How Big is the Market?<br />
Respondents indicated anticipated spending for<br />
2003 totaling approximately $550 million, with<br />
slightly less than $150 million expected to be spent<br />
on software alone, with the balance spent on<br />
services and hardware.<br />
Delphi’s estimate for the total 2003 <strong>BPM</strong> market is<br />
$500 million for software only, thus the 500<br />
respondents in this survey would represent slightly<br />
less than a quarter of total spending. This is<br />
conceivable, as the total market will not likely see<br />
more than 2,000 total sales transactions in 2003<br />
(half of that number, or roughly 1,000 total<br />
transactions is more likely for 2003 <strong>BPM</strong> sales).<br />
Anticipated spending follows roughly a 1-to-3 ratio<br />
of dollars spent on software versus hardware and<br />
services. The single largest area of anticipated<br />
spending is integration services. This expectation<br />
is justified when viewed through the lens of<br />
historic deployment costs of <strong>BPM</strong> models that rely<br />
heavily on new EAI infrastructure. For more<br />
contemporary approaches which leverage<br />
capabilities such as API introspection, the<br />
integration cost should be much lower, closer to<br />
a 1-to-1 software/services ratio.<br />
The average project size for 2003 is roughly<br />
$300,000 with a range of less than $100,000 and<br />
a handful of projects expected to be greater than<br />
$5 million. A few dozen projects were indicated in<br />
the $2 - $5 million range, which is consistent with<br />
the activity Delphi has seen reported by vendors<br />
in this space. Overall, we anticipate that projects<br />
in the $250,000 - $500,000 range will likely be<br />
initial deployments with the potential to grow<br />
beyond $1 million in the next 2-3 years.<br />
While it is possible to identify a mathematical<br />
average, it is not as easy to identify a “typical”<br />
project size or to set expectations for prospective<br />
buyers as to what they should anticipate spending.<br />
This number will vary according to the type of<br />
deployment, the up-front design and analysis, and<br />
of course the size of the deployment in terms of<br />
active users. But it can be assumed that anything<br />
more than a small pilot will cost $100,000 or more<br />
in software and at least as much in services.<br />
Total Anticipated 2003 Spending<br />
on <strong>BPM</strong> = $550 Million<br />
Integration<br />
Services<br />
(39%)<br />
Other<br />
Consulting<br />
(13%)<br />
Software<br />
(26%)<br />
Hardware<br />
(21%)<br />
Respondents were asked to identify the<br />
total dollars anticipated to be spent on:<br />
<strong>BPM</strong> Sofware (not including EAI, app<br />
servers and other infrastructure);<br />
Integration Services; Other Consulting<br />
Services; and new Hardware specifically<br />
required for anticipated or current <strong>BPM</strong><br />
deployments. Answers were aggregated<br />
to provide the break out illustrated above,<br />
and individually analyzed to provide the<br />
ratios shown below.<br />
Services/Hardware<br />
vs. Software<br />
Average<br />
Multiple<br />
Max<br />
Multiple<br />
Standard<br />
Deviation<br />
Software/<br />
Hardware<br />
1.32<br />
10.00<br />
1.38<br />
Software/<br />
Services<br />
2.42<br />
20.00<br />
2.89<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Platform Expectations<br />
21<br />
Deployment Platforms for Current<br />
and Future <strong>BPM</strong> Initiatives<br />
Respondents were asked a series of questions<br />
relative to their preferences and expectations for<br />
<strong>BPM</strong> deployment platforms. Of these (but not<br />
charted here) was whether or not <strong>BPM</strong> will remain<br />
independent of operating system or app server<br />
platforms. Approximately two-thirds indicated<br />
<strong>BPM</strong> will be absorbed by the platform within 3<br />
years, with the same percentage (although a<br />
different set of respondents) answering that such<br />
should happen based on their own preferences.<br />
Until this convergence occurs, which although an<br />
inevitability will not likely happen for at least 2-3<br />
years, the deployment environment for <strong>BPM</strong><br />
solution remains a consideration. With the 2003<br />
survey we saw a subtle drifting in the direction of<br />
J2EE. Yet the greatest shift is seen in the direction<br />
of heterogenous environments. Nearly 60% of<br />
respondents indicated different front-end<br />
environments from their preferred or anticipated<br />
back-end platforms.<br />
The increased reliance of XML for storing process<br />
definitions, the complete abstraction of the data<br />
management layer, and the growing leverage of<br />
Web services is starting to obviate the platform<br />
limitations which dominated just a few years. At<br />
this stage we firmly maintain that this is no single<br />
“right” platform choice, and that the pursuit of<br />
heterogeneous environments are a realistic goal.<br />
We have seen successful deployments co-mingle<br />
Windows infrastructure with J2EE applications.<br />
Examples include the integration of<br />
Windows-based SAP deployments with J2EE-based<br />
<strong>BPM</strong> servers, as well as the use of UNIX servers for<br />
transactional data and Windows or Web-based<br />
front-end environments. We have also seen cases<br />
where a premature “rush to J2EE” was apparent,<br />
and unnecessary in light of Windows-based<br />
options that also offer a reliable migration path to<br />
J2EE. This opportunity should be further<br />
enhanced by the maturing of .NET, which has<br />
recently started to affect <strong>BPM</strong> solution choices (by<br />
offering components within a Microsoft<br />
environment comparable to those seen with J2EE).<br />
J2EE/Web-only<br />
Web front-end,<br />
Microsoft back-end<br />
Microsoft front-end,<br />
J2EE back-end<br />
Web front-end,<br />
UNIX back-end<br />
Microsoft Only<br />
Anticipated Platform for<br />
Future <strong>BPM</strong> Deployments<br />
16.8%<br />
16.8%<br />
15.0%<br />
26.9%<br />
24.5%<br />
0% 10% 20% 30% 40% 50%<br />
Respondents were asked to identify the<br />
anticipated platform for future <strong>BPM</strong><br />
deployments. Where an app server(s) is<br />
expected to be used, respondents were<br />
asked to indicate which from the list<br />
presented below. What is most notable<br />
about the 2003 findings was the large<br />
percentage using open source options of<br />
JBoss or Oracle 9iAS (who licenses the<br />
Orion open source app server).<br />
IBM WebSphere<br />
BEA WebLogic<br />
Oracle 9iAS*<br />
JBoss*<br />
Sun ONE/iPlanet<br />
Other<br />
*Not Identified in the 2001 Survey<br />
App Server Choices for<br />
Future <strong>BPM</strong> Deployments<br />
3.4%<br />
7.3%<br />
17.0%<br />
14.1%<br />
23.8%<br />
30.3%<br />
22.9%<br />
23.9%<br />
34.5%<br />
39.4%<br />
2003 Survey<br />
2001 Survey<br />
0% 10% 20% 30% 40% 50%<br />
©2003 Delphi Group<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
<strong>BPM</strong> Standards<br />
22<br />
The Role of Standards in <strong>BPM</strong><br />
If Samuel Clemens (a/k/a Mark Twain) were alive<br />
today, he might observe that "The nice thing about<br />
standards is that there are so many to chose from."<br />
The notion of a standard in software development<br />
implies as single method or specification, yet with<br />
every new market multiple "standards" always<br />
emerge. Over time these rearrange like soap<br />
bubbles on water, with overlapping specs merging<br />
into a single standard, while some specialized<br />
standards remain intact on their own.<br />
As firms first seek to push the market on their way,<br />
most new software segments initially see several<br />
redundant standards emerge. Yet the only real<br />
value in a standard is when the market picks one<br />
common approach, a process typically hastened by<br />
the support of "gorilla" vendors backing one<br />
standard and forcing competitors to follow suit.<br />
The <strong>BPM</strong> sector has seen a number of standards<br />
and specifications in its space. These include those<br />
from the Workflow Management Coalition, such as<br />
XPDL, Wf-XML and SWAP, to those designed for<br />
Web Services choreography (notably WSCI and<br />
BPEL), as well as the core Web services standards<br />
of SOAP, WSDL, and UDDI. Add to this a mix of<br />
public interface standards such as ICE,<br />
CommerceNet, RosettaNet, and OASIS’ ebXML BPSS<br />
(Business Process Specification Schema).<br />
It is this deluge of standards that many firms in a<br />
recent Delphi survey cited as their single greatest<br />
criticism of the software standards process, such<br />
that buyers (the most vote in a standards process)<br />
have not yet fully weighed-in on the <strong>BPM</strong><br />
standards front. Yet another problem, as the<br />
findings below clearly illustrate, is that the<br />
market's awareness of <strong>BPM</strong> standards remains<br />
fairly low. Respondents were asked to rank their<br />
perceived value of the list of standards and<br />
consortia shown in the chart to the right.<br />
We admittedly mixed apples and oranges in this<br />
list, as Workflow Management Coalition (WfMC) is<br />
not a standard, but is responsible for a number of<br />
standards/specifications such as XPDL. The same<br />
is true for <strong>BPM</strong>I.org and <strong>BPM</strong>L. UML 2.0 is not<br />
specific to <strong>BPM</strong>, but often shows in requirements<br />
documents for <strong>BPM</strong> (albeit not always advisedly).<br />
Yet rather than anointing any single standard, the<br />
goal of this exercise was to determine the market's<br />
attitudes towards the discrete set of standards and<br />
consortia most commonly associated with <strong>BPM</strong>.<br />
Findings were generally consistent with our own<br />
expectations. Standards in place the longest have<br />
the greatest perceived benefit, yet in general<br />
consortia such as the WfMC and BMPI.org still<br />
have a significant education burden in front of<br />
them before they are viewed as "must haves"<br />
among buyers. One surprise, however, was that<br />
for an audience so overwhelmingly predisposed<br />
to process management, both WfMC and BPEL<br />
ranked lower than we would have expected.<br />
In fairness to the WfMC, they received the highest<br />
vote of confidence from respondents. In most<br />
competitive bids Delphi Group has seen in the last<br />
12-18 months, membership in the WfMC is a very<br />
common requirement for <strong>BPM</strong> software suppliers.<br />
As such it was surprising to see the fine degree of<br />
differentiation among respondents’ rankings<br />
between this decade old organization and<br />
<strong>BPM</strong>I.org, who has been in place less than 3 years.<br />
It would be premature to announce the WfMC’s<br />
decline. Yet the close proximately of its rankings to<br />
<strong>BPM</strong>I undoubtedly will offer fodder to those<br />
pushing the notion of the younger consortia as the<br />
WfMC successor. This argument is largely rooted<br />
Workflow<br />
Management<br />
Coalition<br />
UML 2.0<br />
<strong>BPM</strong>I.org<br />
<strong>BPM</strong>L<br />
RosettaNet<br />
BPEL<br />
XPDL<br />
©2003 Delphi Group<br />
Recognition of Existing <strong>BPM</strong><br />
Standard Initiatives<br />
Greatest<br />
Importance<br />
Moderate<br />
Importance<br />
15% 58% 27%<br />
14% 60% 25%<br />
12% 54% 34%<br />
11% 49% 41%<br />
11% 64% 25%<br />
8% 43% 48%<br />
7% 40% 53%<br />
Little to<br />
No Importance<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
<strong>BPM</strong> Standards<br />
23<br />
in the notion that <strong>BPM</strong>I is more contemporary in<br />
its focus and approach, while the WfMC is<br />
concerned more with earlier workflow<br />
management models. There is some merit to that<br />
argument, yet there is significant parallelism<br />
between their efforts.<br />
For most of its existence, the WfMC’s focus has<br />
been the development of five interfaces between<br />
application connection points, similar to what is<br />
illustrated in Figure 1 on page 6. These have<br />
evolved to incorporate the use of XML and other<br />
standards that have evolved over the last decade.<br />
The goal of <strong>BPM</strong>I has been largely the same --<br />
to develop three specific standards (<strong>BPM</strong>L, <strong>BPM</strong>N,<br />
and BPQL) which allow a common set of definition<br />
to interoperate across any compliant <strong>BPM</strong> system.<br />
In essence, to define the components of a<br />
“standard” <strong>BPM</strong>S based on the three constituent<br />
standards. Although the two sets of specifications<br />
are in many ways competitive, the two groups have<br />
collaborated on making them interoperable.<br />
Although it is certainly possible that both will<br />
continue to co-exist, a more likely scenario is that<br />
key specifications are extracted from the larger<br />
“stack”, such as WfMC’s XPDL co-existing with<br />
<strong>BPM</strong>I’s <strong>BPM</strong>L (which is already under discussion<br />
by the two groups). Also shaping this is whether<br />
BPEL emerges as the winning standard for process<br />
execution, which seems likely will happen.<br />
Pronounced “bipple” it is officially named<br />
BPEL4WS or “business process execution language<br />
for Web services” but more popularly known as<br />
BPEL. BPEL v1.0 was initially submitted for public<br />
review by Microsoft, IBM and BEA Systems in<br />
August 2002, replacing the combined work of<br />
Microsoft's XLANG and IBM's WSFL. Following<br />
some concern within the market over large<br />
vendors dominating the specification, a coalition<br />
of vendors including IBM, Microsoft, BEA Systems,<br />
and SAP submitted BPEL v1.1 to the standards<br />
body OASIS in April of 2003.<br />
BPEL is declarative language for describing<br />
process definitions, meaning that it allows<br />
compliant process execution engines to run BPEL<br />
definitions as executable code. In this way it is<br />
similar in its design and intent to <strong>BPM</strong>L, yet BPEL<br />
lacks some of former’s finer grain process syntax.<br />
This is an advantage for <strong>BPM</strong>L today, however, it is<br />
by no means one that cannot be resolved over time<br />
as the specification evolves.<br />
In the case of BPEL and <strong>BPM</strong>L, both lack the<br />
complexity of syntax to describe the full set of<br />
capabilities for every <strong>BPM</strong> solution. Both would<br />
need to further evolve to see market acceptance as<br />
a true standard among <strong>BPM</strong> vendors.<br />
This fact is evident in the initial coalition of<br />
vendors behind BPEL, who are application and<br />
infrastructure vendors (SAP, Microsft, BEA Systems,<br />
et al) and as such cannot design or support the<br />
more complex processes developed by <strong>BPM</strong><br />
vendors. Since its acceptance by OASIS, however,<br />
<strong>BPM</strong> vendors already aligned with <strong>BPM</strong>I.org in<br />
what is more likely a legitimate move to align the<br />
two, rather than a matter of defection.<br />
While it is unlikely the buy-side of the market will<br />
support the continued existence of three sets of<br />
standards with BPEL, <strong>BPM</strong>I and XPDL, neither<br />
alone offer a complete set of specifications for<br />
adequately describing an entire <strong>BPM</strong> solution.<br />
Lacking in <strong>BPM</strong>L, XPDL, and BPEL, for example, is<br />
a process modeling method capable of translating<br />
graphical models into executable process<br />
definitions. <strong>BPM</strong>I’s <strong>BPM</strong>N or “Business Process<br />
Modeling Notation” specification is designed for<br />
this purpose, to provide graphical notations for<br />
expressing business processes and is designed to<br />
translate these into <strong>BPM</strong>L or (eventually) BPEL.<br />
As specifications evolve and converge, a likely<br />
shake-out will be the engulfing of <strong>BPM</strong>L by BPEL.<br />
This leaves <strong>BPM</strong>N as a likely contender for the<br />
modeling requirements these two lack on their<br />
own. XDPL was designed as a process interchange<br />
standard and is currently used by some <strong>BPM</strong><br />
vendors for storing process definitions. But it<br />
lacks a graphical notion outside of <strong>BPM</strong>N (which<br />
is currently being mapped to XPDL). The<br />
advantages of XDPL over BPEL will inevitably lead<br />
to advancements in the latter, with the likely longterm<br />
scenario (greater than 12 months) being the<br />
co-existence of <strong>BPM</strong>N and BPEL.<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Fuego Product Assessment<br />
24<br />
Product Assessment: Fuego<br />
Overview<br />
Incorporated as a US-based company in 1999,<br />
Fuego was one of the first commercial software<br />
vendors to differentiate <strong>BPM</strong> as a unique<br />
discipline, distinct from EAI and applicationcentric<br />
workflow. Fuego was arguably the first to<br />
promote the concept of services orchestration over<br />
discrete automation and integration. Fuego is a<br />
privately held firm that has raised $45 Million in<br />
venture capital since its founding. Fuego is a<br />
independent software vendor focused on a single<br />
application suite, Fuego (formerly Fuego<strong>BPM</strong>).<br />
Orientation and Positioning<br />
Fuego is a <strong>BPM</strong> solution focused on "business<br />
services orchestration" or more broadly stated,<br />
the ability to develop a virtual catalog of<br />
componentized services from new and existing<br />
applications, and to define executable business<br />
processes able to invoke these services, then<br />
manage the execution and lifecycles of both<br />
processes and components. Architecturally, Fuego<br />
is not a single packaged application but a set of<br />
development, execution and management<br />
resources composed of six core modules:<br />
1. Process Designer – GUI-based, drag-and-drop<br />
process development environment, used to map<br />
processes, define business rules and edit syntax.<br />
2. Component Manager – server-side<br />
resource for developing business<br />
objects and managing library of<br />
application service components,<br />
presentations and integration<br />
points.<br />
3. Orchestration Engine – run-time<br />
environment for executing<br />
processes, business rules, and<br />
invoked application.<br />
4. Work Portal – J2EE-compliant environment for<br />
managing Work Lists (e.g., the process end user<br />
environment).<br />
5. Process Analyzer – OLAP reporting and analysis<br />
tool for analyzing process performance metrics;<br />
two cubes are pre-built: Process Workload and<br />
Process Performance<br />
6. Organization Administrator – server-side<br />
manager of roles, organizational structure and<br />
calendars.<br />
These modules, as well as their role in <strong>BPM</strong><br />
and services orchestration are described below.<br />
Process Modeling & Definition<br />
Processes are defined using the Fuego Process<br />
Designer, a GUI-based, drag-and-drop modeling<br />
environment with integrated scripting and<br />
debugging tools. Fuego presents a set of process<br />
design shapes that represent specific functionality<br />
(e.g., AUTOMATIC activity shape represents a<br />
process-to-system Activity; INTERACTIVE activity<br />
shape represents a process-to-human participant<br />
(GUI) Activity) but users can set preferences to use<br />
UML or user-defined icons with vertical or<br />
horizontal "swim lanes" used to identify roles that<br />
participate in a given process.<br />
Models can be developed using one set of shapes<br />
and "hot swapped" to another using a basic switch<br />
in the Process Designer model, or simultaneously<br />
developed in multiple modes by multiple<br />
designers. In this way, Process Designer is<br />
effectively methodology-agnostic in its visual<br />
metaphor. Process models are expressed in XML<br />
(using the XPDL schema) beneath the presentation<br />
layer, and compiled as executable Java code when<br />
published.<br />
Example Fuego Process Model<br />
Fuego’s process modeling tool technology<br />
partners, ProActivity and Proforma, have<br />
developed integration gateways which allow<br />
models in these environments to be translated into<br />
Fuego compliant models (specifically WfMC’s<br />
XPDL with Fuego Extensions). With existing<br />
models from these vendors, or UML models, there<br />
is insufficient syntax to define the level of service<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Fuego Product Assessment<br />
25<br />
interaction capability within Fuego. What they<br />
provide, however, is a means to leverage other<br />
process optimization initiatives or model designs.<br />
The third-party simulation and modeling tools<br />
also enable better integration of business concepts<br />
into the development process – by providing<br />
closed-loop reporting and analysis on process<br />
optimization.<br />
Fuego uses a Visual Basic like scripting language to<br />
define business rules for managing workflow,<br />
accessing, transforming and executing process<br />
objects, external applications, and data sources.<br />
Process Designer provides an IDE-type<br />
development environment for developing CIL<br />
instructions, and includes a syntax checker and an<br />
interactive debugger to test the business rules and<br />
services interactions.<br />
Process Designer supports collaborative design<br />
and development of process models and service<br />
interactions. This can be done hierarchically, with<br />
high-level flows designed by a business analyst<br />
and more granular service instructions developed<br />
by an application architect. This separation<br />
between business and technical functionality<br />
supports the objective of Fuego to enable<br />
processes to be defined by business users rather<br />
than programmers – a requirement reinforced by<br />
several data points in the survey detailed in this<br />
report.<br />
Development can also be done by a team of<br />
analysts simultaneously working on separate<br />
process elements. The security mechanism for<br />
controlling versions of subcomponents is handled<br />
by the LDAP security sign-in or with a third-party<br />
source code manager. Basic documentation is<br />
automatically generated and can be enhanced<br />
during process model definition in the Process<br />
Designer module.<br />
Process Execution<br />
Once defined within the Process Designer,<br />
processes are published as executable Java code to<br />
run and be managed by one or more of the Fuego<br />
Orchestration Engines. These Orchestration<br />
Engines provide the execution and management of<br />
all business process and business services accessed<br />
through the component manager (described later).<br />
Multiple Orchestration Engines can be deployed as<br />
a federation with a single engine designated to<br />
manage interaction between them.<br />
Communication between engines can be done via<br />
TCP/IP, as well as XML/SOAP over HTTP or HTTPS.<br />
Live Process Updates<br />
Live changes to process definitions or process<br />
parameters defined with the Fuego Organization<br />
Administrator (e.g., roles, calendars, etc) can be<br />
made on-the-fly without having to stop and restart<br />
a process instance. This enables the manner in<br />
which Fuego uses the notification mechanisms of<br />
an LDAP Server to poll for resources used by the<br />
Orchestration Engine when executing a process<br />
step.<br />
Fuego Work Portal<br />
Another point of separation between Fuego and<br />
alternative approaches for automation and<br />
integration is the ability to support manual<br />
activities and end-user participation. The Fuego<br />
Work Portal is the end user environment for<br />
engaging participants in process execution. The<br />
Work Portal generates unique work lists for each<br />
user. The Work Portal can be implemented to<br />
leverage LDAP or other directory services for user<br />
authentication, as well as extended to include<br />
external users (i.e., without named accounts) for<br />
B2B processes. The Work Portal can be assigned a<br />
URL for browser access or embedded in another<br />
web application.<br />
Another notable aspect of Fuego is the ability to<br />
define and maintain roles, organizational structure<br />
and calendars within the Fuego Organization<br />
Administrator. This can be used to enable rolebased<br />
routing of process objects, or combined with<br />
rules to enable escalation of process steps<br />
according to schedules and/or responsibilities.<br />
Process Integration<br />
What immediately differentiates Fuego from other<br />
process management approaches is the manner by<br />
which it enables application integration. Fuego<br />
employs a form of integration that is similar in<br />
approach to what is used by portal software<br />
vendors for building "portlets." Where it differs,<br />
however, is that the result contains not only<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Fuego Product Assessment<br />
26<br />
presentation logic (e.g., same as portlets), but also<br />
machine-readable instructions for how to invoke<br />
the component as an application service.<br />
Fuego's approach is distinct from the publish/<br />
subscribe model common to message-oriented<br />
integration middleware. Rather than relying on<br />
EAI infrastructure, such as connectors and<br />
message brokering, Fuego instead relies on the<br />
ability to define rules using its scripting language<br />
to describe where and how to access data and<br />
application services, then wraps these into<br />
individual components that are exposed as<br />
consumable services to process designers.<br />
This is accomplished by introspecting metadata<br />
from an API (Application Programmer Interface)<br />
to determine the interface points of the application<br />
for which access is sought. Introspection is an<br />
aspect of componentization that presents a<br />
standard means of generating self-describing<br />
software components. In the simplest sense,<br />
introspection is analogous to the recipe and<br />
ingredients list on a box of cake mix (the former<br />
representing "cake metadata"). In a software<br />
context, it is the practice of providing metadata<br />
that describes how to invoke an application<br />
through its API.<br />
In essence, introspection allows one application to<br />
read another's interfaces and data structures,<br />
without requiring explicit knowledge of how that<br />
application was deployed. The use of introspection<br />
is found in applications and APIs developed in<br />
recent versions of Java (since the release of JDK 1.2<br />
and the introduction of Java Foundation Classes)<br />
and is inherent in Enterprise Java Beans (EJBs), as<br />
well as other component architectures such as<br />
CORBA and COM/DCOM.<br />
In application environments with limited<br />
introspection, such as SAP's BAPI (Business<br />
Application Programming Interface), Visual Basic<br />
can be used or create a COM wrapper, or where<br />
available, the SAP DCOM Object Builder can be<br />
used. Outside of SAP, various other tools are<br />
available to enable introspection, yet in virtually<br />
all cases the process of exposing metadata is far<br />
simpler than building application-to-application<br />
integration. In a case where customer adapters<br />
are already in place, these provide sufficient<br />
introspection and can also be used. An example<br />
of Fuego being used to orchestrate SAP application<br />
services is illustrated in the case study at the end<br />
of this section.<br />
With Fuego, scripts are used within the Process<br />
Designer to define the syntax for accessing<br />
applications. Once a component has been<br />
cataloged using introspection to determine the<br />
structure of data tables, available data variables,<br />
input parameters, and the specific pieces of data or<br />
application functionality needed, during the<br />
creation of the process model the process designer<br />
uses the component needed to product some result<br />
– i.e., display a User Interface, access a data record.<br />
An example might be "Get Invoice" and as such the<br />
scripts instructions define where to find an<br />
invoice, which input variables are needed<br />
("Customer #", etc), and how the invoice appears<br />
when received. Once the instructions are defined<br />
and encapsulated as a component, the component<br />
is cataloged within the Fuego Component Manager<br />
as a resource for the Fuego Process Designer and<br />
ultimately the Fuego Orchestration Engine.<br />
This cycle (building components) is an essential<br />
element of the Fuego eco-system and its<br />
significance should not be lost in the technical<br />
granularity of its description. In short, the Fuego<br />
Component Manager presents a universal access<br />
point for virtualizing data and applications into<br />
consumable services. The Fuego Orchestration<br />
Engine orchestrates the sequence in which these<br />
services are utilized or consumed.<br />
This illustrates the essence of service orchestration<br />
versus integration and automation. While<br />
integration and automation are by-products of this<br />
process, the Fuego approach (of directly accessing<br />
application services and data) allows for optimal<br />
use of existing automation, with minimal<br />
investment in integration.<br />
Leveraging Web Services<br />
The component-oriented modules of Fuego<br />
(notably the Component Manager) allow for<br />
applications to be virtualized into service<br />
components. The same capabilities extend to<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Fuego Product Assessment<br />
27<br />
pre-existing components, such as Web services<br />
with WSDL descriptors, COM/DCOM objects, EJBs,<br />
Java classes, CORBA, XML, SOAP messages, or<br />
other self-describing software. These can also be<br />
registered or "cataloged" with the Component<br />
Manager as executable services. The degree of<br />
autonomy and self-description dictates the amount<br />
of effort and scripting required registering them.<br />
But once cataloged, each component is a service<br />
available to any Fuego process with a single<br />
method of invocation.<br />
Fuego allows for integration logic (how to find and<br />
invoke data and applications) to be abstracted and<br />
managed separately from process logic (how these<br />
services are used). This approach is in contrast<br />
with more traditional pairings of process<br />
management and EAI, where specific integration<br />
points are defined but not otherwise exposed as<br />
services. Rather than building integration logic<br />
into the process, the Component Manager provides<br />
a single method for accessing data and<br />
functionality from a broad set of systems and<br />
application types.<br />
In this sense, the Component Manager is<br />
orthogonal to the message bus used in publish/<br />
subscribe-type, message-oriented integration.<br />
Where these two part ways, however, is that the<br />
output of a message bus is meaningless to a<br />
process engine and serves only as a means for<br />
getting data from one point to another.<br />
In contrast, the Component Manager produces a<br />
result that is 100% consumable by the<br />
Orchestration Engine. Further, while the<br />
Component Manager is abstracted from the rest of<br />
the Fuego application modules, it is by design and<br />
definition far more tightly integrated than any<br />
third-party EAI software could be. It is looselycoupled<br />
with fine-grained interaction.<br />
Process Monitoring & Maintenance<br />
Executing Processes are managed by the<br />
Orchestration Engines. Inherent in the design of<br />
these engines are basic systems management<br />
capabilities, from back-up procedures and<br />
performance monitoring, to the ability to "listen"<br />
for execution problems and restart failed servers.<br />
A two-phase commit protocol is used to persist<br />
transactions and process state. In the event of<br />
failure, if the transaction was automated (e.g., an<br />
invoked application) it is rolled back to the<br />
previous state and restarted. If the transaction was<br />
a manual activity, the work item is sent back to the<br />
appropriate work list in the Work Portal.<br />
Fuego also provides a fail-safe mechanism through<br />
a system of one primary and multiple secondary<br />
Orchestration Engines. All Orchestration Engines<br />
are connected to one another notifying each other<br />
to check if they are active. If the primary<br />
Orchestration Engine stops working, one of the<br />
secondary Orchestration Engines will take the role<br />
of primary Orchestration Engine, managing the<br />
automatic and user generated transactions.<br />
Reporting<br />
Fuego Process Analyzer provides multidimensional<br />
OLAP reporting tools and analysis<br />
capabilities for analyzing process performance<br />
metrics captured by the Execution Engines.<br />
Extensions are provided for third-party report<br />
tools, such as Crystal Reports, however, there are<br />
comparatively sophisticated report design and<br />
analysis tools within Process Analyzer. Process<br />
Analyzer also allows for the creation of<br />
"dashboard" type live reports based on a discrete<br />
set of performance metrics. There are two<br />
predefined analysis cubes – Workload and Process<br />
Performance.<br />
Technology Platforms<br />
Fuego is a J2EE application framework requiring a<br />
Java Virtual Machine (JVM) to operate, as well as<br />
LDAP or SQL-compliant directory services, a Webserver<br />
(with a servlet container) or an application<br />
server, and a relational database. JVM (JDK 1.3 or<br />
higher) platforms supported including Windows<br />
NT or higher, as well as most major Unix variants<br />
(including Linux).<br />
Fuego supports any relational database with JDBC<br />
drivers, but already tested and verified are Oracle<br />
8i (Standard and Enterprise editions), Microsoft<br />
SQL Server (7.0 and higher), IBM DB2 (7.0 and<br />
higher), and Cloudscape.<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Tesoro Case Study<br />
28<br />
Standards Participation<br />
Fuego participates in various standards bodies and<br />
industry groups within the business process<br />
software space, including <strong>BPM</strong>I.org, ITAA, UDDI<br />
and RosettaNet. Both J2EE standards (JMS, JDBC,<br />
JNDI, JAAS, etc) and XML is used throughout the<br />
Fuego architecture, including process definitions<br />
that use the XPDL schema (the Workflow<br />
Management Coalition's XML Process Definition<br />
Language). Fuego is also exploring BPEL<br />
(discussed earlier in this report) as this<br />
specification evolves.<br />
Case Study: Tesoro Petroleum<br />
Highlights<br />
Orchestration of Existing Islands of Automation<br />
Distilling Complex Systems Into<br />
a Single Presentation Layer<br />
Reduced Training Requirements<br />
Improving the Accuracy, Timeliness,<br />
and Completeness of Data<br />
Improved Process Efficiency & Faster<br />
Inventory Turn-Over<br />
Cultural Shift From Packaged Software<br />
to Service Orchestration<br />
Deployment Environment<br />
Large-scale SAP deployment on Microsoft<br />
infrastructure.<br />
Case Study Overview<br />
Tesoro Petroleum is an $8 billion petroleum<br />
refining company in San Antonio, TX, using<br />
Fuego’s <strong>BPM</strong>S to address what Tesoro's CIO<br />
describes as the areas of "white space" across a<br />
major, multi-system SAP deployment. Tesoro<br />
estimates that close to 95% of its business runs on<br />
top of SAP. Fuego is used to acquire and post data<br />
to and from the SAP system, as well as to<br />
orchestrate user-centric processes that would be<br />
difficult (if not impossible) to define within SAP or<br />
through traditional EAI software.<br />
Problem Statement<br />
When the SAP system was built, Tesoro designed<br />
with a process-oriented architecture, rather than<br />
focusing on a single or set of software modules.<br />
This involved the development of a library of<br />
business scenarios and related documentation<br />
defining business processes. In this way, the SAP<br />
system covers the vast majority of the processes<br />
executed by Tesoro. What is left is the "white<br />
space" – the places in process requiring human<br />
intervention, as well as other disconnects between<br />
the flow of a business process and the specific<br />
application functions (i.e., SAP and other systems<br />
within a given process). Filling in this white space<br />
was the driver behind Tesoro's pursuit of a <strong>BPM</strong><br />
solution.<br />
Tesoro's problem was not one of automation but<br />
orchestration. Automation was already achieved<br />
through its significant investment in SAP. The<br />
challenge for Tesoro was to bridge the complex<br />
and distributed islands of automation through<br />
orchestration of discrete transactions within endto-end<br />
processes. A cultural challenge for Tesoro,<br />
was that after being an SAP shop for many years<br />
it was necessary to develop an application<br />
development discipline consistent with building<br />
the reusable components required to leverage<br />
orchestration strategy, rather than focusing on the<br />
configuration of packaged software (as is the case<br />
with SAP). Related to this was the need to develop<br />
a business analysis competency required to define<br />
end-to-end processes with enough granularity and<br />
validation to handle the necessary hand-offs<br />
between applications and users.<br />
Product Evaluation Process<br />
Tesoro required process management system able<br />
to deliver on two objectives:<br />
1. Define end-to-end processes that complement<br />
and extend the processes and automation<br />
already built within SAP (e.g., filling in the<br />
white space), and<br />
2. Allow for granular, yet intuitive definition of<br />
business processes such that they can be<br />
understood and refined by non-IT,<br />
business-oriented personnel.<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Tesoro Case Study<br />
29<br />
Tesoro began in 2001 with a survey of possible<br />
alternatives to address these issues. What they<br />
found, however, was that most options with the<br />
requisite integration capabilities were focused<br />
only on application-to-application transactions,<br />
and lacked the ability to define user-interfacing<br />
process steps.<br />
Consistent with the philosophy presented<br />
throughout this report, Tesoro understood the<br />
goal of <strong>BPM</strong> is to incorporate the people side<br />
of business processes with the application and<br />
systems side. Tesoro did look closely at leading<br />
integration platforms as a possible solution, but<br />
soon determined these were insufficient to<br />
address user-centric requirements.<br />
This led Tesoro to look beyond EAI solutions for<br />
an application that addressed the white space<br />
where individuals work outside of, or in concert,<br />
with other systems (rather than simply shuttling<br />
data between systems). Fuego was selected to<br />
create a process orchestration layer between users<br />
and systems. In this way Fuego provides the<br />
common presentation layer for users, then is able<br />
to parse-out and distribute pieces of a single user<br />
transaction and distributes the appropriate data to<br />
the three applications.<br />
Order-to-Cash<br />
Anything that has to do with inventory movements<br />
is a high priority for the oil refinery industry, and<br />
Tesoro is no exception to this. Oil is an expensive<br />
product to keep in inventory, and the goal of<br />
Tesoro is to move from the point of an order to the<br />
receipt of payment (read "cash") in the shortest<br />
time possible.<br />
This is what initially drove Tesoro to make such a<br />
sizable investment in SAP. Yet the inefficiencies<br />
remained at the points where discrete systems<br />
present hand-offs to users or other applications.<br />
Fuego is used to roll-up these discrete transactions<br />
across a given process (such as sales order entry)<br />
into a single transaction for SAP, ensuring the<br />
complete and most expedient entry of data, and<br />
negotiating the proper hand-offs between<br />
individual users.<br />
For any given sales transaction, the process<br />
involves creating a contract, then creating a sales<br />
order, then billing documents (payables and<br />
receivables), prior to payment. Across this process<br />
the same data needed to create a contract is<br />
required to be entered into three different systems<br />
(sales, goods, billing), which otherwise (prior to<br />
Fuego) requires three individuals to manually<br />
entered with each order.<br />
Areas of potential breakdown or inefficiency<br />
within this process include incomplete or<br />
erroneous data entered at any point, thus stalling<br />
the process or (worse) sending it back to be<br />
redone; inherent delays waiting for data to be<br />
entered; and the manual process of chasing down<br />
missing information.<br />
To resolve this, Tesoro built a portal interface with<br />
Fuego, which collects and validates all the<br />
information needed to complete a sales order, with<br />
each user seeing the environment appropriate for<br />
their own role, then rolls this up into a single<br />
transaction before it is posted to the appropriate<br />
SAP applications.<br />
Validation & Accuracy<br />
Service orchestration capabilities (such as those<br />
provide by Fuego) have opened the gates to far<br />
more and easier options for exposing and<br />
orchestration application functionality than was<br />
otherwise available with prior platform and EAI<br />
opportunities.<br />
Yet making use of these resources requires that<br />
the data driving these applications is precisely as<br />
is should be, or that the point of entry for data has<br />
the intelligence to resolve when this is not the case.<br />
Failing to resolve this presents a significant point<br />
of failure within any process management<br />
initiative. In Tesoro's case, it was determined that<br />
this difference represented 5 times the cost to<br />
make a correction to data within SAP than it does<br />
to enter it correctly the first time.<br />
Responding to the issues above, one of the first<br />
benefits Tesoro realized through its deployment<br />
of Fuego was to improve accuracy of both new<br />
and existing data posted to the SAP applications.<br />
©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com<br />
Reproduction authorization required.
Tesoro Case Study<br />
About This Document:<br />
The product-specific<br />
information contained in this<br />
document is intended to<br />
provide an overview of a<br />
specific product and vendor at<br />
the date of publishing. Facts<br />
presented have been verified to<br />
the best of our ability with the<br />
vendor and actual users of the<br />
product where indicated,<br />
however, Delphi cannot insure<br />
the accuracy of this<br />
information since products,<br />
vendors, and market conditions<br />
change rapidly. Delphi Group<br />
makes no implied or explicit<br />
warranties, endorsements, or<br />
recommendations in this report<br />
nor should such warranties be<br />
inferred from its contents. A<br />
complete assessment of your<br />
specific application, the method<br />
of implementation for a given<br />
product or technology, and the<br />
current state of that product<br />
must be considered in order for<br />
a recommendation to be made<br />
on any product’s suitability for<br />
your purpose, needs and<br />
requirements.<br />
Delphi Group is a leading<br />
provider of business and<br />
technology advisory services to<br />
Global 2000 organizations. With<br />
offices established around the<br />
world, Delphi has assisted<br />
professionals across disciplines<br />
and industries at nearly every<br />
major national and global<br />
organization and branch of<br />
government. Its clients and<br />
subscribers include more than<br />
half of the Global 2000.<br />
Delphi Group<br />
Ten Post Office Square<br />
Boston, MA 02109-4603<br />
v (617) 247.1511<br />
f (617) 247.4957<br />
Within the front-end of the Fuego environment (presentation layer)<br />
Tesoro defined rules and validation procedures, which while transparent<br />
to the user, allowed greater over the quality and accuracy of data entered<br />
or updated within the system.<br />
As part of the same, completeness is also improved by validation that<br />
all information for a particular transaction is present, and if not Fuego<br />
invokes an activity to either obtain it from the appropriate system or<br />
prompts the user to update it. Timeliness is also improved as Fuego<br />
facilitates more on-line data entry, rather than relying on faxes and<br />
manual entry.<br />
Componentization and Orchestration<br />
Tesoro used the SAP BAPI structures wrapped with COM (Common<br />
Object Model) to enable introspection. This, Tesoro reports, required<br />
about one month's development time, with another month spent<br />
developing the Fuego components and process definitions to orchestrate<br />
the SAP application services. Tesoro also used Fuego to authenticate<br />
SAP users using Active Directory (the directory services used internally).<br />
During this process Fuego was also used to create a common presentation<br />
layer that masks the complexity of the underlying SAP systems. This single<br />
environment replaced multiple SAP screens, reducing training costs, error<br />
rates and overall intimation from had been at times a bewildering SAP<br />
environment.<br />
Of equal significance, however, was that the use of Fuego enabled Tesoro<br />
to make a major architectural shift without changing its underlying<br />
infrastructure. What had been a single application tier with multiple<br />
accessing points and interfaces, was transformed into a three-layer<br />
architecture:<br />
Presentation Layer – a single means for access all systems through the<br />
Fuego Work Portal<br />
Orchestration Layer – the execution of process, validation and posting<br />
of data, and orchestration of servers, accomplished by Fuego and<br />
transparent to users<br />
Application Layer – Existing SAP systems and Microsoft infrastructure<br />
This presents an extensible infrastructure for deploying new processes<br />
and orchestrating additional services, without having to alter the user<br />
environment or back-end infrastructure. Looking forward, Tesoro is<br />
examining how they can address issues such as Sarbanes-Oxley<br />
Compliance with the Fuego <strong>BPM</strong>S. The incremental approach enabled by<br />
Fuego will allow for existing work to be leveraged in this process, such as<br />
monitoring SAP transactions for possible compliance violations.<br />
www.delphigroup.com