BPM WP FileNET

A Delphi Group White Paper 

BPM2003 

Market Milestone Report 

Contents 

Methodology ............................ 2 

Defining BPM ........................... 4-6 

Process Orchestration ............ 7 

Phases of Orchestration ......... 8 

Orchestration & 

Virtualization ........................... 9 

Orchestration Summary ........ 10 

Components of BPM ............... 11 

What’s Missing From 

Current Offerings .................... 12 

Product Selection Criteria ..... 13 

Defining Business Logic......... 14 

BPM Benefits ............................ 15 

Integration Priorities ............. 16 

Requirements for 

Software Suppliers .................. 17 

Current State of 

BPM Deployments ................... 18 

Investment Size & 

Pricing Models ......................... 19 

BPM Market Size & 

Momentum ............................... 20 

Platform Expectations ............ 21 

BPM Standards ........................ 22-23 

Fuego 

Product Assessment ................ 24-27 

Tesoro 

Case Study ................................ 28-30 

Fuego, Inc. 

2400 Dallas Parkway 

Plano, TX 75093, USA 

P (972) 801-4200 

F (972) 801-4201 

www.Fuego.com 

Featuring a Delphi Group 

Assessment of: 

Enabling the New Mission for IT 

Today's IT challenges are defined as much by what is in place already as 

by what might be missing. We have lived through the "killer app" era, 

having spent the last two decades building islands of automation with 

packaged software. But the legacy left by these systems is an integration 

problem that today consumes the lion's share most IT budgets. 

While the challenge of integration remains largely unsolved, it has 

nonetheless moved further to the forefront after years of custom 

application development, a rising tide of regulatory pressure (now 

presenting criminal liability thanks to the Sarbanes-Oxley Act), and for 

many firms a morass of system complexity after waves of M&A activity. 

Forced to contend with these new challenges in the face of IT dollars 

being increasing consumed by integration and maintenance costs, it is 

of no surprise that Business Process Management has seen such a rapid 

rise in interest over the past year. Yet the real value of BPM is not simply 

that of a cheaper means for integration, but rather as a resource to 

channel existing automation into orchestrated business processes. 

Today we are also on the cusp of what may very well be the final great 

boom of the software industry, and the last frontier for generating value 

from IT infrastructure. Born from the need to keep pace with a 

continuously changing business environment, this phase will be led by a 

new mandate for software virtualization, componentization, and 

orchestration. 

If this is starting to sound like Web services, it should. But to lay this 

entire opportunity at the feet of Web services would miss the point 

entirely. Web services are an enabler, not an end-state. Simply exposing 

applications as services will take us little beyond where we are today. 

As is illustrated in this report, the true linchpin for the realization of 

this opportunity is the ability to connect these components through a 

framework of orchestrated business processes --- to transform automation 

infrastructure into reusable business assets. This is the new charter for 

the partnership of business and IT, and the real value offered by today’s 

generation of BPM software.

2 

Methodology 

This report is based on a combination of a recent 

Delphi survey and additional analysis by Delphi 

Group's research team. 

The charts in this report present the findings from 

the Q2’03 survey with responses from 500 

individual users and evaluators within firms 

across multiple industries worldwide. 

Approximately 75% of responses are from the U.S. 

Respondents varied in their roles from current 

users of BPM to project sponsors and business 

analysts. Approximately 75% of respondents are 

presently engaged in either deploying or 

evaluating BPM software. 

The Q2’03 survey follows a Q4’01 research 

initiative executed for the 2002 BPM Market 

Milestone Report. At specific points in this year’s 

survey, questions are intentionally repeated from 

the Q4’01 survey to demonstrate and validate the 

evolving opinions, attitudes and behaviors within 

the BPM market. Where this was done, charts and 

data are presented with both years’ findings 

juxtaposed to demonstrate contrast. 

Throughout this report, the survey findings are 

presented to illustrate concepts and trends, in 

addition to the quantified results represented 

within the charts. As definitions and perspectives 

vary between individuals and across organizations, 

examining the contrast in responses offers clearer 

reflection of the true state of the market than any 

single statistic alone. 

Sponsor Initiative(s) 

(15%) 

Evaluate BPM 

Solution 

(6%) 

Identify 

Requirements 

(13%) 

Sponsor 

BPM 

Initiative(s) 

(19%) 

Current Role With 

BPM Deployments 

Develop BPM 

Software (3%) 

Acquire BPM Solution 

(Not Sponsor) (9%) 

BPM 

End User 

(44%) 

Lead or Participate 

on Deployment Team 

(10%) None (3%) 

None (10%) 

Future Role With 

Future BPM Deployments 

End User 

(19%) 

In the final stage of this research initiative, Delphi 

Group’s research interviewed a set of BPM software 

vendors and their customers. The results of these 

interviews have shaped the analysis presented in 

this report, and are also presented at the end as a 

set of individual case studies and product profiles. 

Define IT 

Specifications 

(23%) 

Define 

Business 

Requirements 

(25%) 

©2003 Delphi Group • Ten Post Office Square, Boston, MA 02109-4603 • v(617) 247-1511 • www.delphigroup.com 

Reproduction authorization required.

3 

Report Highlights 

BPM = Workflow + EAI 4 

The Anatomy of 

Process Management 4 

Orchestration vs. Automation 7 

Web Services and 

Process Orchestration 7 

Process Orchestration 

Myths and Realities 10 

Whole-Product Requirements 11 

Market’s Perspective 12 

Product Selection Criteria 13 

Business Software for a 

Business Audience 14 

What’s in it for IT? 15 

Integration Priorities: 

The Market’s Perspective 16 

Who Gets The Deal? 17 

The Market Comes of Age 18 

How Big a Deal? 19 

How Big is the Market? 20 

Deployment Platforms for Current 

and Future BPM Initiatives 21 

The Role of Standards in BPM 22 

Product Assessment: Fuego 24 

Case Study: 

Tesoro 28 

Table of Charts & Figures 

Current Role With BPM Deployments 2 

Future Role in With Future 

BPM Deployments 2 

Current Definitions of BPM 4 

Figure 1 - Conceptual Model of BPM 6 

Figure 2 - An Automated Process 9 

Figure 3 - An Orchestrated Process 9 

Process Management Software Landscape 10 

Necessary Components of Any BPM Solution 11 

Features Missing From BPM Solutions 12 

Overall Functional Priorities Driving 

Product Selection Criteria 13 

Project Sponsor for BPM Investments 14 

Responsibility for Defining Business 

Rules & Process Logic 14 

Single Greatest Functional Advantage 

Anticipated from BPM 15 

Single Greatest IT-Specific Benefit 

Anticipated from BPM 15 

Integration-Specific Priorities 

Driving Product Selection Criteria 16 

Direction of Increasing Priority 16 

Financial Criteria for BPM Software Suppliers 17 

Investment Timing for Firms Without 

Current Deployments or Initiatives 18 

State of BPM Deployments 18 

Reasons Cited for Not Investing in BPM 18 

Preferred Pricing Model for BPM Investments 19 

Total BPM Software-Only Spending 

Anticipated Over the Next Three Years 19 

Financial Role for BPM Deployments 19 

Total Anticipated 2003 Spending on BPM 20 

Services/Hardware vs. Software 20 

Anticipated Platform for Future 


App Server Choices for Future 


Recognition of Existing BPM 

Standard Initiatives 22 



Defining BPM 

4 

BPM = Workflow + EAI 

Nearly half of respondents to the 2003 survey 

identified most closely with the definition of BPM 

as an emerging software layer for building processbased 

applications. This is an increase over 2001 

and represents a better than 5-to-1 advantage 

over any other answer. 

This reflects the fundamental shift towards crossfunctional 

processes (i.e., across multiple 

applications). After spending two decades building 

“islands of automation” with packaged software, 

organizations today are looking to bridge the gaps 

these have left across operational processes. 

The growing trend to address this has been greatly 

influenced (and vice versa) by changes in software 

development that have led to easier separation 

of business processes from applications, fueled 

in no small part by the Internet and Web services. 

In the same manner that the emergence of SQL 

and the two-tier client/server architecture enabled 

the abstraction of data management from 

application code, the emergence of N-tier 

computing and component-oriented environments 

(such as COM and J2EE) allow for the abstraction 

of business processes from application logic. 

By separating business process management as 

an independent function, applications can be 

designed around existing processes, and thus to 

take advantage of shared business logic rather 

than reinventing and recoding it for each 

application. 

An emerging layer of 

software for building new 

process-based applications 

Just rebranding 

of old-style workflow 

A subgroup of EAI software 

The latest buzzword 

about to be dominated 

by Microsoft, IBM, SAP, et al 

Have no strong opinions 

too early to tell 

©2003 Delphi Group 

Current Definitions of BPM 

12.3% 

19.4% 

11.7% 

12.1% 

4.4% 

4.8% 

12.3% 

9.7% 

59.2% 

54.0% 

2003 Survey 

2001 Survey 

0% 10% 20% 30% 40% 50% 60% 

The notion of cross-functional processes 

inevitably brings to mind application integration, 

which is no doubt responsible for much of the 

confusion between BPM and EAI. With these 

results, however, the market shows a clear and 

appropriate bias towards the independence of BPM 

from EAI or data-centric integration software. 

While the market seems clear on this distinction, 

BPM has nonetheless been pigeon-holed by many 

analyst firms as merely a subgroup of EAI. To do 

so, however, is to miss the point of BPM’s 

fundamental value to the enterprise. 

BPM is not about linking applications, per se, nor 

about defining the transformation logic involved 

in extracting data from applications. This may be 

a subset of what a BPM solution offers, yet the real 

value of BPM is the ability to define and execute 

business processes independent of applications 

and infrastructure. While EAI and integration 

capabilities offer an important resource to BPM 

environments, integration software typically lacks 

the ability to address the user-facing side of 

business processes. This is consistent with the fact 

that EAI is concerned foremost with app-to-app 

exchange of data, not user activity or interaction. 

The Anatomy of Process Management 

To make sense of how BPM fits with organizations 

and infrastructure, it is helpful to examine the 

individual components of BPM. While commercial 

systems vary in their specific definitions and 

software composition, most fit within the basic 

framework described below. Note that although 

some systems (ERP and HRMS for 

example) offer the ability to automate 

activities and define business rules, those 

that lack the fundamental components 

below cannot realistically be used as a BPM 

system. 

A BPM system is defined by the 

components of an Execution Engine, 

Process Designer, Process Definitions, an 

Activity Monitor, and user interface which 

may be a combination of Windows client 

application, HTML-based Work Portal, or 

an exposed API or Web service (see the 




5 

model on page 6 for an illustration of how these 

pieces work together). 

For the vast majority of BPM systems on the 

market today, application architectures are 

component-oriented and allow each of the 

individual pieces listed above to be deployed 

independently on individual servers, or (albeit 

less commonly) as COM or EJB components. 

Individual business processes are defined in a 

Process Definition and increasingly expressed in 

some variation of XML (additional details on XML 

standards for Process Definitions are provided in 

the ‘Standards’ section of this report, pages 22-23). 

Each Process Definition may be composed of both 

Manual Activities and Automated Activities. Once 

defined and validated within the Process Designer, 

Processes are instantiated by an Execution Engine. 

An instantiated Process Definition is a Process 

Instance. The state, status and history of each 

Process Instance are persisted into an external 

data store (this is true today of any commercially 

viable BPM system as none use internal databases 

as early systems once did). The Activity Monitor 

provides access to status and performance metrics 

on the execution of Process Instances. While all 

systems provide some form of an Activity Monitor 

or reporting mechanism, they vary according to 

the degree of control over granularity of reports 

and whether or not “live” data can be accessed. 

The Execution Engine controls the state and 

execution of each Process Instance, which are 

composed of multiple Activity Instances. Activity 

Instances represent the process activities (also 

called Tasks or Steps) during execution, and 

include both Work Items and Invoked Applications. 

Invoked Applications are automated 

activities involving some form of a system-tosystem 

transaction, such as a stored procedure 

or a Web service. 

Work Items are manual activities distributed 

to human users or process participants. These 

may be a process exception that requires 

manual intervention, or a process step that by 

definition always requires human input. 

When a process instance is executed, Work Items 

are generated in response to activities and process 

rules, and distributed by the Execution Engine into 

an appropriate user’s Work List. The Work List is a 

collection of Work Items from one or more process 

instances, each with its own state and status. Work 

lists represent the integration between process 

participants and process instances. Process 

participants access Work Items from the work list, 

which is coordinated by the Execution Engine. 

In this way (i.e., managing the exchange of Work 

Items between users and systems) process 

management is undeniably similar in appearance 

to message queuing and other asynchronous 

approaches to application integration (EAI). 

Yet it should be understood that managing 

processes is not about data flow or moving data 

from one bucket to another, nor responding to 

discrete events in isolation, but managing flow 

control across an entire business process instance. 

The ability to include manual activities as part 

of the process (i.e., rather than simply part of an 

error handling routine) is a subtle but significant 

point of differentiation between BPM and EAI. 

Generating Work Items and managing Work Lists 

requires the Execution Engine to have access to 

user identities (i.e., through Directory Services) 

and access privileges. Roles and interrelationships 

(such as team structures) can be defined and 

managed within the BPM system, but architecture 

of most systems on the market today leverage 

authentication and directory services from 

existing infrastructure using standard interfaces 

such as LDAP, JNDI and Active Directory. 

Handling Work Items is a critical role of the 

Execution Engine and underscores the importance 

of managing manual activities (Work Items) 

separately from transactional activities (Invoked 

Applications). For example, ensuring the integrity 

of executed processes requires both the ability to 

initiate compensating actions if a transaction fails 

and to identify when a specific activity requires 

human intervention. This requires a broader 

perspective (i.e., process-wide) than is otherwise 

provided from individual transactions. 




6 

For example, the J2EE framework offers an 'ACID' 

test for the integrity of discrete transactions 

(defined vis-à-vis the four properties of Atomicity, 

Consistency, Isolation, and Durability). This is an 

important enabler for the BPM system to ensure 

the integrity and completion of individual process 

steps. However, ACID as a specification does not 

adequately address the need for state management 

across long-running transactions and business 

processes. Similarly, while J2EE session beans 

enable state to be held or passed from one 

transaction to another, they are not capable of 

managing higher-level business logic or flow 

control across the execution of a process. 

Rather, this level of control and coordination 

requires an Execution Engine to manage state 

changes generated by each activity instance across 

an initiated process. This also allows the 

Execution Engine to initiate corrective actions 

based on process definitions and business rules. 

Figure 1 - Conceptual Model of BPM 

User Environment 

Work Items 

& Work List 

Process Designer 

Defines 

Process Definition 

BPM System 

Generates 

Instantiates 

Invokes 

Execution Engine 

Updates 

Activity Monitor 

Accesses 

This may involve time limits defined within the 

process definition to trigger the prompting for 

user response, or process logic may require that 

routing be changed based on the state changed 

in an activity instance. 

The ability to manage state and process logic also 

allows the Execution Engine to facilitate hand-offs 

between process participants (person-to-person) 

and manage interactions between users and 

applications. For example, when a work item is 

delivered to the work list, the Execution Engine 

can pass on both the state from the previous 

activity and the description of what to do from 

the process definition (which may also be 

conditionally modified based on the state). 

Coordinating hand-offs between users 

distinguishes the role of the Execution Engine as a 

means of optimizing the performance of processes, 

rather than simply executing rules or code. This is 

accomplished in part by passing on Englishlanguage 

instructions and activity descriptions 

within a process object, as well as with manual 

Third Party 

Applications 

& Automated 

Activities 

Security & 

Directory 

Services 

Validates 

Persists 

Operational 

Data 

activities where written instructions 

are delivered through a work item. 

In this manner, the Execution Engine 

allows autonomous execution of 

individual activities, while maintaining 

the continuity and integrity of the 

executed process. While no company 

keeps its knowledge workers on a 

production line, it should still be 

evident how BPM enables more 

efficient utilization of human resources 

by facilitating the execution of work. 

Specifically, by bringing work directly 

to users with the process context and 

task information necessary to execute 

each step, rather than having them 

waste trying to figure out what to do, 

what they need and where to find it. 

This also illustrates another key benefit 

of BPM systems versus the alternative 

approaches of application integration 

and automation. 



Process Orchestration 

7 

By facilitating the execution of manual activities, 

the BPM system is not automating work (as parts 

of the process still consist of human work), but 

rather it is orchestrating the process. 

The Execution Engine manages the sequencing 

and distribution of activities, as well as parameters 

such as data variables captured or updated, time 

constraints on activities, and the state of activities. 

Yet the performance of work is left to human 

workers, not scripted into application code. 

This again presents a subtle yet significant 

difference that clearly illustrates the value of BPM 

software. Just as manual activities can be defined 

and managed within a process without having to 

code every action, processes can be defined within 

a BPM system based on specific goals and 

outcomes without having to explicitly define 

every step. This presents the notion of process 

orchestration, which differentiates BPM from 

traditional workflow automation. 

Orchestration vs. Automation 

The basic notion of orchestration involves the 

development of executable processes as a set of 

loosely-coupled activities, rather than explicitly 

coded steps. Yet the concept of orchestration is 

rooted in the fundamental shift of application 

design towards the delivery of software as a 

service, evolving from the maturation of both J2EE 

and Web services. This shift has shaped both the 

philosophy and fundamental technologies behind 

nearly all software development today. 

A simple definition of an application is a set of 

activities or use-cases strung together for a 

specific purpose or function. The philosophy that 

governed application development until only 

recently was that of building an amalgamation of 

activities through which business and application 

logic are inseparable. As is vivid in virtually every 

enterprise today, the inevitable result is a rigid and 

virtually unmanageable morass of code. 

Certainly a better approach is to build as a 

collection atomic activities, connected and 

coordinated by a separate layer of business logic. 

This approach has slowly emerged through the 

evolution of N-tier application architectures, 

driven by the ability to leverage existing services 

from the platform and infrastructure. A necessary 

piece missing from component-based platforms 

such as J2EE and Microsoft (COM and .NET), 

however, is the independent process layer. 

Web Services and Process Orchestration 

Although componentization and its inherent 

benefits of software reuse has been common 

within the world of J2EE programming, the 

emergence of open standards for integration 

(most notably the Web services stack of SOAP, 

WSDL, XML and UDDI) presents a standard, 

application-independent means for components 

to be exposed as a library of invokable services. 

Connecting two points (i.e., reading into a single 

application from another) is not by itself 

revolutionary. What is, however, is building 

libraries of components into a vast network of 

distributed services. This is the concept of 

software virtualization, or what is increasingly 

referred to as a Service-Oriented Architecture 

(SOA). 

While most of the attention focused on SOA 

has been largely dominated by Web services, 

it is important to realize that these standards 

are merely one of the means to an end and not 

the end game itself. The true value of SOA comes 

from the ability to orchestrate these components 

across executable business processes. 

Bridging the Islands of Automation 

By definition, the use of Web services presumes 

that automation is already in place (i.e., Web 

services enables connectivity between automated 

activities), yet very often this exists as the 

proverbial "islands of automation" with no 

visibility between them. One system might handle 

the shipping documents, with another 

coordinating shipping schedules, and another 

tracking shipping status. Thus each system is 

responsible for a discrete function, yet lacks the 

ability to determine if or where a process may have 

broken down within any of the related but 

otherwise disconnected systems. 



Phases of Orchestration 

8 

Whether or not your business involves shipping 

products, this is nonetheless likely to be a familiar 

scenario for any firm that has invested in 

automation without orchestration. One approach 

to this problem would be to integrate these 

otherwise disparate systems with EAI. Yet this 

would not address the need for process 

coordination, would not help with handling 

exceptions, and would still come at a very high 

deployment cost. Exposing these application 

capabilities as Web services would offer visibility 

without the inherent rigidity of EAI, and thus over 

the long-term would be more cost effective to 

maintain. But Web services alone would do little to 

help coordinate processes across these systems. 

The First Phase of Orchestration 

Most BPM systems on the market today can 

“consume” Web services. In other words, when 

Web services are registered within a standard 

directory (UDDI) and wrapped with a standard set 

of descriptors (WSDL and XML) they can be 

invoked by a BPM system as an automated activity. 

Many BPM systems allow Web services to be 

“discovered” from within the process designer and 

added to the design palette, such that they can be 

added to the process definition without requiring 

any other formal integration effort. 

The standard Web services interfaces describe to 

the BPM system how to invoke the service and 

what data variables can be sent to and/or from the 

service. Depending on the complexity of the 

service, these data variables are either mapped 

within the process designer or automatically 

added to the process definition requiring only 

basic validation during the design process. 

This represents the significant first stage of 

moving from automation to orchestration, by 

combining process management with Web 

services. It allows for external applications and 

data to integrated into executable business 

processes with minimal programming effort 

compared to what would otherwise be required. 

It also leverages the inherent flexibility of Web 

services over other integration approaches. Since 

it is expressed as a Web service, the service 

component is self-describing and self-contained. 

Changes within the application (such as adding a 

new data table or moving up to a new system 

version) will be resolved through the Web services 

definition and not require a redesign of the 

process. Anyone who has dealt with other forms of 

EAI knows full well the problems involved with 

application changes breaking integration 

connections. In the context of live processes, these 

changes will bring work to a screeching halt. 

However the combination of Web services and 

process management also allows the ability to 

design processes based on specific goals and 

outcomes, without having to explicitly define every 

possible permutation or flow path. Just as with a 

manual activity, within an orchestrated process a 

step can be defined as "Check Shipment" or "Notify 

Receiver" (using the example earlier in this 

section) and as such invoke a Web service to 

retrieve shipping status or send out a notification 

based on a specific set of input variables. To do 

this within a traditionally automated process 

would require volumes of coding. 

The Next Phase of Orchestration 

Beyond consuming Web services, the next stage of 

orchestration is to use the BPM systems 

specifically to enable software virtualization. 

Although the Web services architecture is 

increasingly adopted by application developers 

such as SAP and PeopleSoft, as well as platform 

vendors such as IBM and Microsoft, the most likely 

scenario is that application capabilities desired are 

not exposed services and may not have the 

descriptive metadata required to easily access 

without integration. 

This presents two obvious options: using 

proprietary application adapters, or building 

proprietary integration points. Pursuing either 

option outside of a BPM system (i.e., for the 

purpose of accessing these within process 

definitions) is an expensive proposition in terms 

of either the cost of application adaptors or the 

cost of development time or both. 

Addressing this from within a BPM system offers 

two similar options, yet in most cases at a 

much lower price point. This also likely includes 



Orchestration & Virtualization 

9 

leverage of standard interfaces such as ODBC, 

COM/DCOM or J2EE interfaces such as JAAS, JTS, 

JDBC, and JNDI. But for proprietary systems other 

means of entry are required. 

Many BPM systems on the market today offer the 

option of a pre-integrated library of application 

adapters. These carry with them two important 

caveats: 

1) there is no such thing as a “universal 

adapter” as every application requires some 

modification of data structures; and 

2) adapters are typically designed for a specific 

version, which must be synchronized with the 

connected applications. 

What pre-integrated adapters do allow, however, is 

the ability to define integration points within the 

process designer and enable easier access to 

applications than would be available with 

proprietary EAI. Once integrated, this allows 

application services to be registered once and 

reused throughout process definitions. 

The second approach is to enable integration 

syntax directly within the process designer. BPM 

systems which offer this capability typically 

delineate separate levels of abstraction --- one 

which defines business and flow logic, and another 

which defines integration logic. These also allow 

the registry of application services as individual 

components, enabling them to be included within 

the designed palette and reused throughout the 

process definition. 

Certainly, neither approach offers 

a “magic bullet” to application integration. 

Any integration effort 

will require significant development time 

and effort to introduce external 

application services to process 

management. What these 

alternatives do offer over other 

approaches, however, is specifically 

that -- allowing application services 

to be introduced to process 

management rather than trying to 

manage processes around 

application functionality. 

Figure 2 - An Automated Process 

Figure 2 above illustrates a typical 

automated process, where each step is 

defined explicitly in terms of all possible 

permutations and outcomes. 

Figure 3 below illustrates the same 

process based on an orchestration 

strategy, where steps are defined as 

autonomous activities or invoked 

services. The same level of control flow 

is enabled in both examples, however, 

the orchestrated process offers a far 

more streamlined design and fewer 

points of failure (by defining steps in 

terms of outcome rather than scripted 

rules). 

Figure 3 - An Orchestrated Process 



Orchestration Summary 

10 

Process Orchestration Myths and Realities 

The role of orchestration in process management 

offers a vivid illustration of evolutionary advances 

of current BPM software over earlier approaches to 

process automation. It should be noted that 

orchestration is not a “quick fix” for managing 

processes without proper analysis of business 

logic. 

What an orchestration-based approach does offer 

is the ability to manage processes of greater 

complexity with far more efficiency than is 

otherwise possible with alternative approaches. 

The key to this is a modular approach to managing 

business rules, relationships, and activities. 

Within an automation paradigm, processes are 

defined “end-to-end” with all possible paths (or 

more commonly a single path) pre-determined. 

Thus ‘Step #5’ always follows ‘Step #4’ and precedes 

‘Step #6’ even if different instances of an otherwise 

standard process may require a different sequence. 

Orchestration allows for the sequencing of steps to 

be determined during the “run-time” instance of a 

process, with paths determined by evolving context 

resulting from each new step. Thus the potential 

number of paths and outcomes may otherwise be 

too complex to define in terms of pre-determined 

“If-Then-Else” rules, but may be easily resolved 

through human interaction and decision-making. 

This highlights the key architectural difference 

between automation and orchestration. Given the 

inherent complexity and constant changes within 

any “real world” business environment, effectively 

managing processes requires the agility to shift 

with changes in context, rather than always being 

bound to the same scripted flow. This requires the 

unique ability to define processes as a set of 

atomic, goal-based activities with the enforcement 

of basic parameters (e.g., time limits, data 

variables), while separating the execution logic 

activities from the higher-level process definition. 

As discussed throughout this section, process 

orchestration presents the intersection of process 

management and Web services. To be clear, 

however, process orchestration should not be 

confused with other emerging approaches of Web 

services orchestration and choreography. Process 

orchestration is not limited to invoking software, 

but rather represents a shift from task-based to 

goal-oriented process definition. Web services 

and other forms of software automation are 

utilized through process orchestration, yet not to 

the exclusion of manual, human-driven activities. 

When examining the process management 

software space, differentiation should be made 

between automation and orchestration, as well as 

between service-oriented processes versus contextdriven 

process management focused on 

coordinating both manual and automated 

activities. BPM software products overlap one 

or more of the categories defined below. 

Process Management 

Software Landscape 

Orchestration-Centric 

Service-Oriented 

Supports processes 

involving the coordination 

of external application 

services. Enables both 

consuming and generation/ 

publishing of services from 

external applications. 

Provides fine grain control 

over invoked services. 

Workflow-Driven 

Supports processes with 

a discrete number of 

predetermined steps, 

paths, and outcomes. 

Supports invocation of 

external services through 

data exchange only. 

Context-Driven 

Supports process flow paths 

dependent on the outcome 

of previous steps. Enables 

orchestration processes 

where all possible path 

permutations and process 

outcomes cannot be 

pre-defined. 

Rule-Driven 

Supports the ability to 

define and resolve 

discrete business rules. 

Rules engines use 

If-Then-Else definitions 

to resolve process 

conditions and events. 

Automation-Centric 



Components of BPM 

11 

Whole-Product Requirements: 

Market Expectations 

In an effort to assess the market’s priorities for 

whole-product requirements, respondents were 

asked to identify which components they believe 

should be either self-contained (i.e., proprietary), 

pre-integrated (i.e., third-party component 

integrated by vendor) or independent (i.e., 

integration left to deploying organization). 

As stated earlier, the combination of these 

components represents the basic configuration 

of any viable BPM solution (with the exception of 

the App server). The objective with this research, 

however, is to determine the market’s expectation 

for best-of-breed software options for BPM. Not 

surprisingly, two-thirds of respondents view 

BPM as necessarily independent of the app server 

platform (counter to positioning by vendors 

such as IBM, Oracle, and BEA Systems). 

What is notable among these responses is the 

high ranking of business rules engines as a 

core component. This runs counter to the 

fact that rules engines have been largely 

abstracted from application software “stacks” 

and are today widely available as independent 

services. The likely explanation for this is 

the market’s expectations for the ability 

to define business rules within 

process definitions, using the 

process designer. 

Many vendors leverage separate rules engines, 

rather than seeking to replace already deployed or 

otherwise off-the-shelf options available on the 

market today. 

Combining functions of business rules and 

process execution, as well as activity monitoring, 

presents the capabilities found in the sub-segment 

of “BPM engines” on the market today. These 

represent an emerging class of software 

applications focused specifically on introducing 

process execution capabilities to existing 

applications and new development initiatives. 

Typically independent BPM engines work across 

multiple deployment environments. This also 

means that no deployment environment (i.e., app 

server) is provided, and thus anticipates that target 

applications will have the necessary deployment 

infrastructure in place. Similarly, in contrast with 

other offerings that base differentiation on the 

completeness of built capabilities, independent 

BPM engines focus foremost on lightweight 

deployment overhead and are designed to leverage 

existing infrastructure wherever possible. Through 

the use of component-based architectures, many 

BPM solutions also offer execution engines alone 

as OEM offerings for other software vendors. 

Necessary Components of 

Any BPM Solution (ranking by respondents) 

Should Be a 

Core Component 

of Any BPM Solution 

Vendor Should 

Pre-Integrate 

Best-of-Breed Alternatives 

Definitely Should 

Be Indepdent 

No Answer 

Given 

Business Rules Engine 67% 26% 7% 

Execution Engine 

(manage process instances) 

Process Activity Monitor 

Directory Services (Define and Manage 

Users, Roles, Teams, etc) 

Analytical Reporting 

& Performance Metrics 

Integration Platform 

Work Portal 

(access BPM work list) 

Application Server 

64% 27% 7% 3% 

60% 33% 7% 0% 

49% 39% 12% 0% 

45% 41% 12% 1% 

45% 41% 12% 2% 

44% 42% 13% 2% 

31% 46% 22% 1% 



What’s Missing From Current Offerings 

12 

Market’s Perspective: 

As shown at the bottom-right chart, respondents 

were asked to indicate from a provided list of 

capabilities which of those were perceived to be 

missing from current BPM solutions. This was a 

“check all that apply” choice and as such the most 

relevant take-away from this is not individual 

numbers but the contrast between each category. 

The fact that process model standards featured so 

prominently on this (cited by nearly half of all 

survey respondents) indicates this to be a 

significant issue among BPM users and evaluators. 

The next two highest ranking responses are related 

to process modeling if not interchange standards 

directly. Combined these reinforce the importance 

of the development environment as well as the use 

of BPM as tool for enabling process improvement. 

This is consistent with the results from a related 

question (illustrated below) where respondents 

were asked to identify their single greatest priority 

for investing BPM. 

Enterprise-wide Redesign 

of Business Processes 

Data-Level 

Application Integration 

Rule-based or Event-Drivern 

Document Routing 

Enforce Business Rules 

With Trading Partners 

Define & Map Business 

Processes 

Monitor Staff Performance 

& Activities 

Ensure Integrity of 

Internet Transactions 

Extend Existing Apps 

11.0% 

18.9% 

9.9% 

13.9% 

9.3% 

7.4% 

8.8% 

8.2% 

6.5% 

4.1% 

4.5% 

5.7% 

4.0% 

4.1% 

46.0% 

37.7% 

2003 Survey 

2001 Survey 

0% 10% 20% 30% 40% 50% 

Respondents were asked to identify 

their Single Greatest Priority for BPM 

deployments from the list shown above. 

Enterprise-wide process redesign was 

favored nearly 5-to-1 over integration or 

other choices provided, representing a 

significant shift over responses in 2001. 

Reality: 

Enabling the interchange of process models has 

been a priority for workflow and (later) BPM 

vendors since the beginning of this industry 

segment. This was one of the initial goals of the 

Workflow Management Coalition (WfMC) with a 

specification known as “Interface 1” and later the 

Workflow Process Definition Language (WPDL). 

Despite some proof-of-concept demonstrations, 

neither standard has featured prominently in BPM 

deployments or offerings. 

What has shifted the landscape for interchangeable 

process models, however, is the use of XML to 

represent process definitions. This has enabled a 

number of proprietary interfaces between process 

modeling tools and process execution engines, as 

well as XML-based standards such as the WfMC’s 

XML Process Definition Language (XPDL). 

The second wave of process standards was 

initiated first by BPMI.org with the development of 

Business Process Modeling Notation (BPMN) for 

model definition and Business Process 

Management Language (BPML) as declarative 

language for process execution. These are 

discussed in detail within the section on standards 

at the end of this report. 

Features Missing From BPM Solutions 

(percent cited from all respondents) 

Standardized Interchange 

of Process Models 

Business Performance 

Management 

Richer Graphical 

Monitoring & Simulation 

Orchestration & Negotiation 

Quality of Service 

Metrics & Monitoring 

Analytical Reporting 

& Monitoring Capabilities 

Transaction Verification 

& Delivery Guarantees 

Usage Metering & Billing 

34.0% 

33.0% 

28.0% 

27.0% 

26.0% 

22.0% 

18.0% 

44.0% 


0% 10% 20% 30% 40% 50% 



Product Selection Criteria 

13 

Product Selection Criteria: 

How Market Evaluates BPM Solutions 

Similar to the exercise to identify market 

perceptions, respondents were asked to rank the 

level of priority for the issues and functions shown 

below with regards to product selection criteria. 

Of the fifteen points of consideration, responses 

were categorized in terms of integration-specific 

criteria (see page 16) and overall functionality 

(below). 

Among issues of overall functionality, those with 

highest negative responses (i.e., instances where 

the lowest priority is placed) relate to platform 

choices, which is understandable given the 

inherent polarity of these choices and the fact that 

a certain percentage of the population will always 

pick one platform over another. 

The area of criteria associated with the greatest 

priority, however, should not be surprising to 

anyone who has gone through a product selection 

process, yet may otherwise be dismissed by some 

as trivial. The criterion in question is the role of 

process modeling environments, which is often 

dismissed by industry pundits as immaterial, 

compared with issues of server performance and 

other more technically oriented matters. Despite 

this, Delphi’s field experience has consistently 

concurred with the findings of this piece of 

research, showing that BPM software evaluators 

very often place a top priority on process 

modeling environments, a factor often 

underestimated by software suppliers. 

Aligned with process modeling priority is the 

need to leverage existing resources and skill sets 

(ranked nearly as high). This ties into the fact 

that most BPM deployments involve the 

development of an internal process team and 

competency. These teams are typically not lead 

by IT (a fact reinforced by findings shown later in 

this report), but rather are made up largely of 

business process owners and users. For this 

reason, process designers must be able to 

accommodate non-technical users. 

The third highest priority is access to integrated 

analytical capabilities and business performance 

monitoring, which also ranked as a close third 

within whole-product requirements. Again, this 

reinforces the notion of BPM as a means of 

enabling continuous process improvement. 

Development trends among BPM vendors reflect 

this requirement, with an increasing number 

including OLAP capabilities and other robust 

report functionality within core product offerings. 

Overall Functional Priorities Driving 

Product Selection Criteria 

Graphical Mapping & Monitoring 

of Business Process 

Leverage of Existing 

Resources & Skill Sets 

Integrated Analytics Engine, or 

Business Performance Monitoring 

Support for J2EE App Servers 

& Related Standards 

Independent Validation of 

Project & Software ROI 

Acccess to a Published Standard 

for Process Modeling & Definition 

Support for Microsoft 

Infrastructure & Standards 


Little to No 

Importance 

Moderately 

Important 

Very 

Important 

Single 

Greatest 

Priority 

8% 29% 53% 9% 

8% 33% 53% 6% 

11% 37% 46% 6% 

21% 29% 45% 5% 

19% 33% 42% 7% 

17% 36% 40% 7% 

30% 23% 40% 7% 

Direction of Increasing Priority 



Defining Business Logic 

14 

Business Software for a 

Business Audience 

As discussed on the previous page, 

BPM deployments are led 

predominantly by line-of-business 

managers and business process owners. 

This is not to suggest that BPM does not 

require the involvement of IT and other 

technical resources. IT will be required 

for BPM just as with any other major 

software deployment. What is unique 

about BPM, however, is the much larger 

role played by traditional business 

(i.e., non- technical) personnel. 

The two most significant components of 

a BPM deployment are defining business logic and 

identifying integration points. This requires the 

ability to express BPM deployment requirements 

in non-technical terms, including process flows as 

well as complex business rules and relationships. 

This requirement highlights the importance of the 

process designer and development environment, 

which holds the potential to be the greatest point 

of failure in any BPM deployment. 

If processes are not properly articulated and 

validated in the design phase, they will of course 

fail upon deployment. Treating end users as the 

test bed for processes not properly validated will 

result in significant culture resistance and 

reluctance to cooperate with further iterations. 

Senior Management, Not CIO 

Individual Process Owners 

or Line-of-Business Managers 


Individual Process Owners 

or Line-of-Business Managers 

Enterprise Architect 

E-Business Leader 

Other Business Analyst(s) 

Outside Consultants 

Other (please specify) 

Internal Programmers 


Project Sponsor for BPM Investments 

CIO (or equivalent) 

Other 

Marketing 

E-Business Leader 

2.6% 

2.1% 

7.2% 

11.6% 

30.0% 

0% 10% 20% 30% 40% 50% 

46.5% 

Responsibility for Defining 

Business Rules & Process Logic 

2% 

2% 

4% 

9% 

12% 

17% 

It is for these reasons that proper definition of 

process logic is necessary for the success of any 

BPM deployment, and why input from business 

process owners is so crucial. 

As stated earlier, most BPM deployments involve 

the development of cross-functional (i.e., IT and 

business) process teams. The lingua franca for 

these teams may initially be flow charting tools, 

but at some point (ideally earlier than later) this 

needs to switch to the actual process design 

environment used to create process definitions. 

The later in the deployment process this segue 

occurs, the greater the probability for the 

misinterpretation of business requirements as 

they are translated into process definitions. 

55% 

This has led some firms to use 

modeling methodologies such as UML, 

that are designed for enterprise and 

application modeling. The caveat with 

methodologies such as UML, or even 

process-specific methods such as IDEF, 

is that these do not allow for fine grain 

articulation of product-specific process 

definitions, and thus run a similar risk 

of misinterpreting business 

requirements. A better approach is to 

select a BPM solution that supports 

business-level process modeling within 

the same environment as more granular 

integration and application syntax. 



BPM Benefits 

15 

What’s in it for IT? 

Respondents were asked to identify 

(separately) the anticipated IT-specific 

benefits and overall functional benefits 

anticipated through deploying BPM software. 

The clear winner among IT benefits is the 

ability to integrate internal applications. 

As this admittedly presents only a limited 

perspective (respondents were forced to pick 

one answer from limited options) further 

definition of integration priorities are 

provided on the next page. 

What these responses do indicate more than 

anything else, however, is the education 

challenge facing BPM vendors. Integration 

ranked fairly low among top priorities as 

shown earlier in this report. Yet a challenge the 

BPM market has faced is lack of recognition for 

other IT-related benefits than integration. These 

include easier (and cheaper) maintenance of 

enterprise software, through the use of 

orchestration capabilities (versus custom-coding) 

to expose application services. As well as the 

ability to develop new capabilities without the 

comparatively higher expense involved with 

building these within existing application 

environments. 

As many CIO’s budgets are today consumed 

largely by application integration and 

maintenance costs, BPM offers a 

high-leverage opportunity for 

addressing new problems such as 

Sarbanes-Oxley compliance (which 

now puts CIOs on the line for 

accounting practices). From a 

business user perspective, the 

greatest benefit of BPM is seen as 

the ability to manage business rules 

and process definitions without 

having to rely on IT for every 

required change. This too should be 

viewed by IT as an inherent benefit, 

as well as a means for enabling 

orchestration over automation (i.e., 

leveraging existing automation 

within applications). 

Change Business & Processs Rules 

Within Enterprise Software 

Without IT Intervention 

Manage Exceptions 

Within Automated Processes 

Ability To Visualize, Simulate, 

& Trouble-Shoot 

Business Processes 

Automate Repetitive Tasks 

& Accelerate Process Cycle Times 

Single Greatest Functional 

Advantage Anticipated from BPM 

Monitor Personnel 

& Process Performance 



Single Greatest IT-Specific Benefit 

Anticipated from BPM 

Cost-Effective Integration 

of Internal Applications 

Accelerate Deployment 

of New Applications 

Reduce Total Cost of Ownership 

of Existing Application 

Integration of Applications 

Outside of The Firewall 

Add "State" to 

Stateless Applications 

Ability to Reuse Software Code 

Other 

Other 

2% 

4% 

8% 

11% 

10% 

10% 

16% 

0% 10% 20% 30% 40% 50% 

15% 

13% 

17% 

41% 

Respondents were asked to pick the 

single greatest advantage from two lists 

of IT-related and general business 

functional advantages. While cost-effective 

integration is clearly favored among 

IT benefits, business benefits are much 

more evenly split. 

24% 

28% 

0% 5% 10% 15% 20% 25% 30% 



Integration Priorities 

16 

Integration Priorities: 

The Market’s Perspective 

When asked to prioritize integration-specific 

product selection criteria, respondents indicated a 

bias favoring cross-application process integration. 

Within the language of the survey, the word 

“orchestration” was not used explicitly, as this is a 

relatively new term which is open to multiple 

interpretations. Yet the desire for orchestration as 

described and defined in this report is clearly 

favored over simply enabling data-level integration 

(both in the results shown below and indicated 

earlier). 

What is equally clear, is that integration in general 

remains a significant priority in most BPM 

deployments. As is illustrated in several different 

charts and findings, integration only falls when 

respondents are asked to identify top drivers of 

BPM initiatives (i.e., where the choice of 

integration is mutually exclusive of other choices). 

This illustrates a central message of this report, 

that BPM is not about enabling point-to-point 

connections between applications, but rather the 

ability to define and orchestrate business 

processes that take advantage of capabilities and 

existing automation within multiple applications. 

Where respondents appear equally split or 

otherwise indifferent within the findings 

illustrated below is when it comes to whether or 

not BPM should be a component of integration 

Connecting Otherwise Disparate Processes 

Across Multiple Software Applications 

software or offered independent of any EAI or 

integration platform. This is a subtle distinction 

in the context of a high-level assessment of BPM. 

Yet for practical purposes, BPM offered as a 

component of EAI will not allow for necessary 

flexibility to enable process orchestration. 

Architecturally, BPM needs to be an independent 

layer which takes advantage of integration 

capabilities, either internally or in partnership 

with third-party EAI offerings. Otherwise, the 

ability for BPM services to be invoked by both 

external applications and user environments 

(work lists) will be compromised. 

Most BPM offerings on the market today present 

some level of integration capability, with varying 

levels and approaches. For BPM initiatives where 

external applications play a large role at multiple 

points across a process, the ability to define 

invocation capabilities within process definitions 

will play a large role in the resulting deployment’s 

agility and performance. For processes that are 

largely collaborative or “people-centric” in design, 

the ability to read data from external applications 

may be sufficient. For enabling orchestration 

across multiple application services, however, the 

BPM solution used must allow for fine grain 

articulation of integration and invocation syntax. 

Integration-Specific Priorities 

Driving Product Selection Criteria 

Little to No 

Importance 

Moderately 

Important 

Very 

Important 

Single 

Greatest 

Priority 

6% 24% 57% 13% 

Integrating BPM Within 

Existing Applications & Initiatives 

Ability to Access Outside 

Data Within the BPM Environment 

Direct Access to API 

Set of BPM Engine 

BPM as a Component of 

or Integrated With EAI 

Independent of Any Single Apps Server, 

EAI Tool, or Enterprise Application 

8% 23% 57% 13% 

8% 26% 57% 9% 

13% 36% 45% 6% 

20% 35% 40% 5% 

22% 36% 37% 5% 

Transaction Processing 

& Load-Balancing 

19% 42% 37% 3% 

©2003 Delphi Group Direction of Increasing Priority 



Requirements for Software Suppliers 

17 

Who Gets The Deal? 

The market for BPM software remains price 

sensitive, with the most common answer by 

respondents that vendor selection will be made 

according to the lowest price. This may be 

disheartening to most BPM vendors, yet it remains 

a reality for most software segments as 

IT budgets continue to shrink relative to available 

dollars (not otherwise earmarked for maintenance 

and integration). This number may be understated 

due to best intentions by some respondents, 

who may change their tune when ultimately forced 

to justify their investments. Thus the percent of 

purchases made based on the lowest bid may 

actually be larger than is indicated here. 

One significant shift seen in the 2003 results over 

2001, however, is the favoring of large brand 

vendors. This too reflects macro trends across 

the software industry, with many smaller vendors 

complaining of what felt to be the unfair scrutiny 

of their size and viability. Yet for the BPM market 

it is too soon for a “Big 3” set to dominate. 

Innovation traditionally flows from upstarts, not 

incumbents. This has been no different for the 

BPM software industry, where large platform 

vendors such as Microsoft, IBM, and Oracle (e.g., 

the traditional software Big 3) have remained 

notably deficient in process management 

capabilities (in particular relative to the offerings 

of much smaller vendors). 

The lack of presence by large 

platform vendors reflects the 

generally nascent state of the BPM 

sector (a market arguably only a few 

years old) and the lack of critical 

mass among large system buyers 

(see pages 19-20 for the size of total 

and individual spending). One factor 

already shaping the competitive 

landscape, however, is the emergence 

of standards driven by the larger 

platform players. 

Most notable is BPEL or Business Process Execution 

Language, submitted to the standards body OASIS 

by vendors including Microsoft, IBM, BEA Systems, 

and SAP. Due to its backing by these large vendors, 

as well as its growing support by “pure play” BPM 

vendors, BPEL is expected by many to emerge as 

the dominant BPM standard. As an adopted 

standard, BPEL would allow a single process 

definition to run on multiple execution engines, as 

well as to exchange process objects between live 

processes running on different systems. 

If BPEL or another standard does mature to allow 

true interchangeability between BPM systems, this 

will put pressure on all BPM players to 

differentiate based on valued-added capabilities. 

Similar to the role that J2EE played on the until 

recently proprietary app server market, a single 

BPM standard should foster innovation by 

removing the threat to software buyers of locking 

into proprietary investments. If in this way 

competitive pressure (vis-a-vis buying criteria) 

shifts from company size to price and 

functionality, the results will be a greater number 

of affordable options for BPM buyers. 

Platform vendors have the opportunity to 

undercut smaller competitors by subsidizing the 

cost of BPM software. But opportunities remain for 

smaller vendors to differentiate on the basis of 

lower overall cost of ownership, with products that 

are easier and cheaper to deploy and maintain (see 

page 20 for a break out of the total cost of BPM). 

Financial Criteria for BPM Software Suppliers 

Will Work With Whoever Provides 

the Best Combination Of Price & Service 

Will Prioritize Selection Criteria 

According to Product 

& Organizational Capabilities 

Only Vendors With 

Dominant Brand Name 

Only Vendors With 

There is an Existing 

Commerial Relationship 

Only Publicly-Traded Vendors 

2% 

3% 

12% 

12% 

17% 

24% 

23% 

32% 

2003 Survey 

2001 Survey 

38% 

36% 


0% 10% 20% 30% 40% 



Current State of BPM Deployments 

18 

The Market Comes of Age -- 

But a Business Case Still Must be Made 

While still in an early stage, the BPM market 

appears to be close to reaching critical mass, with 

the number of early adopter deployments nearly 

doubling since the 2001 survey (indicated by 20% 

of respondents indicating they are using BPM 

already). The high number of firms in the early 

stage of evaluation (nearly half of all respondents) 

indicates that the market is on the cusp of a break 

out. If buyers move as indicated below, 75% of all 

firms responding to this survey will have invested 

in BPM inside of the next three years. 

The single greatest factor suppressing market 

expansion today is the lack of clearly defined 

business case. Combined with the lack of project 

sponsors (a closely related issue) the need to make 

the case for BPM investments has held back more 

than 60% of firms who have not yet invested. This 

illustrates the education challenge facing the 

supply-side of the BPM market. It is of greater 

importance today than price or functionality. 

BPM vendors have the onus of proving the 

business case for any investment regardless of 

price. An effective vehicle for this is the delivery of 

packaged solutions able to demonstrate very quick 

results, such as Sarbanes-Oxley or USA PATRIOT 

Act compliance or domain-specific solutions such 

as those for telecom provisioning . These are 

focused apps built on top of a core BPM platform, 

offering near turn-key deployment now, with a 

defined path for later expanding into other areas. 

Investment Timing for Firms Without 

Current Deployments or Initiatives 

40% 

34% 

Using BPM 

Software Already 

State of BPM Deployments 

Final Stages 

of Deployment 

Early Stage 

of Evaluation 

No Plans 

for BPM 

No Business 

Case 

No Project 

Sponsor 

9% 

4% 

12% 

20% 

23% 

29% 

0% 10% 20% 30% 40% 50% 60% 


Reasons Cited for 

Not Investing in BPM 

28.0% 

24.0% 

28.0% 

2003 Survey 

2001 Survey 

Respondents were asked to identify their 

current state of BPM deployments, and 

where none were planned or in place, 

the single greatest reason for this. 

Findings were largely consistent 

year-over-year, with the most dramatic 

changes relative to firms who have 

invested since the 2001 survey, and the 

growing need for a business case 

among those who haven’t. 

48% 

55% 

36.7% 

Will Use Existing 

Apps/Platform 

17.6% 

18.3% 

9% 

< 6 

Months 

7-12 

Months 

2-3 

Years 

10% 

4-5 

Years 

1% 6% 

> 5 

Years 

Never 

Vendors Unable 

to Meet Needs 

Other 

14.9% 

9.7% 

6.8% 

16.1% 

2003 Survey 

2001 Survey 

0% 10% 20% 30% 40% 50% 



Investment Size & Pricing Models 

19 

How Big a Deal? 

Another sign of market maturity is the shift 

in anticipated spending reported in the “less than 

$100,000” range to anticipated spending between 

$1 million and $5 million. An investment of less 

than $100,000 over a three year period will 

certainly pay for a pilot, but not much more than 

a small deployment. So the decline in category is 

a positive sign for the market overall. 

Investment plans have remained relatively 

consistent, with the subtle shifts favoring larger 

transaction sizes. This is a forward-moving trend, 

and is consistent with what should be seen with 

any market maturity cycle. Where changes are 

most pronounced, however, is in relation to 

anticipated pricing models. The percent of 

respondents whose preferred pricing model is 

by the CPU more than doubled over 2001 findings. 

This trend is consistent with the direction of most 

vendors, particularly with architectures based on 

J2EE. Yet those citing preference for pricing per 

user also increased by more than 60% since 2001. 

Total BPM Software-Only Spending 

Anticipated Over the Next Three Years 

Nothing 

< $100,000 

$101,000 - 

250,000 

$251,000 - 

500,000 

$501,000 - 

1,000,000 

$1,001,000 - 

2,500,000 

$2,500,000 - 

5,000,000 

> $5,000,000 

15.7% 

15.4% 

20.9% 

19.7% 

11.3% 

10.3% 

9.6% 

12.0% 

5.2% 

2.6% 

5.2% 

0.9% 

2.0% 

5.1% 

30.1% 

34.2% 

2003 Survey 

2001 Survey 

0% 10% 20% 30% 40% 50% 


These price increases are at the expense of fixedprice 

and subscription based pricing (including 

SLAs). This trend may reverse or increase, based 

in the effect of new accounting regulations 

(Sarbanes-Oxley most notably) that alter the 

manner in software and other expenses must be 

amortized and recognized. At this point in time 

it is our expectation that subscription pricing 

(e.g., delivery of software as a service) will in fact 

increase in popularity as a result of these 

regulations. 

Single, fixed price 

for development environment 

Price per CPU 

Service Level Agreement 

Price per user 

Subscription fee based 

on processing volume and usage 

Price per process managed 

Preferred Pricing Model 

for BPM Investments 

10.2% 

22.0% 

27.1% 

21.4% 

20.0% 

23.7% 

19.4% 

11.9% 

12.5% 

2003 Survey 

17.8% 

2001 Survey 

4.6% 

3.4% 

Trends in transaction size indicate market 

growth over 2001 survey findings. Within the 

2003 survey, almost 90% of respondents cited 

BPM investments as either generating profits or 

at least netting out with expenses. This indicates 

expectations for positive ROI on BPM, but is also 

consistent with an expectation for deploying 

BPM as part of a for-profit or cost-cutting 

initiative, such as Business Process Outsourcing. 

Financial Role for BPM 

Deployments 

Cost-Neutral 

(42%) 

Cost Center 

(19%) 

Profit Center 

(39%) 


0% 10% 20% 30% 40% 50% 



BPM Market Size & Momentum 

20 

How Big is the Market? 

Respondents indicated anticipated spending for 

2003 totaling approximately $550 million, with 

slightly less than $150 million expected to be spent 

on software alone, with the balance spent on 

services and hardware. 

Delphi’s estimate for the total 2003 BPM market is 

$500 million for software only, thus the 500 

respondents in this survey would represent slightly 

less than a quarter of total spending. This is 

conceivable, as the total market will not likely see 

more than 2,000 total sales transactions in 2003 

(half of that number, or roughly 1,000 total 

transactions is more likely for 2003 BPM sales). 

Anticipated spending follows roughly a 1-to-3 ratio 

of dollars spent on software versus hardware and 

services. The single largest area of anticipated 

spending is integration services. This expectation 

is justified when viewed through the lens of 

historic deployment costs of BPM models that rely 

heavily on new EAI infrastructure. For more 

contemporary approaches which leverage 

capabilities such as API introspection, the 

integration cost should be much lower, closer to 

a 1-to-1 software/services ratio. 

The average project size for 2003 is roughly 

$300,000 with a range of less than $100,000 and 

a handful of projects expected to be greater than 

$5 million. A few dozen projects were indicated in 

the $2 - $5 million range, which is consistent with 

the activity Delphi has seen reported by vendors 

in this space. Overall, we anticipate that projects 

in the $250,000 - $500,000 range will likely be 

initial deployments with the potential to grow 

beyond $1 million in the next 2-3 years. 

While it is possible to identify a mathematical 

average, it is not as easy to identify a “typical” 

project size or to set expectations for prospective 

buyers as to what they should anticipate spending. 

This number will vary according to the type of 

deployment, the up-front design and analysis, and 

of course the size of the deployment in terms of 

active users. But it can be assumed that anything 

more than a small pilot will cost $100,000 or more 

in software and at least as much in services. 

Total Anticipated 2003 Spending 

on BPM = $550 Million 

Integration 

Services 

(39%) 

Other 

Consulting 

(13%) 

Software 

(26%) 

Hardware 

(21%) 

Respondents were asked to identify the 

total dollars anticipated to be spent on: 

BPM Sofware (not including EAI, app 

servers and other infrastructure); 

Integration Services; Other Consulting 

Services; and new Hardware specifically 

required for anticipated or current BPM 

deployments. Answers were aggregated 

to provide the break out illustrated above, 

and individually analyzed to provide the 

ratios shown below. 

Services/Hardware 

vs. Software 

Average 

Multiple 

Max 

Multiple 

Standard 

Deviation 

Software/ 

Hardware 

1.32 

10.00 

1.38 

Software/ 

Services 

2.42 

20.00 

2.89 



Platform Expectations 

21 

Deployment Platforms for Current 

and Future BPM Initiatives 

Respondents were asked a series of questions 

relative to their preferences and expectations for 

BPM deployment platforms. Of these (but not 

charted here) was whether or not BPM will remain 

independent of operating system or app server 

platforms. Approximately two-thirds indicated 

BPM will be absorbed by the platform within 3 

years, with the same percentage (although a 

different set of respondents) answering that such 

should happen based on their own preferences. 

Until this convergence occurs, which although an 

inevitability will not likely happen for at least 2-3 

years, the deployment environment for BPM 

solution remains a consideration. With the 2003 

survey we saw a subtle drifting in the direction of 

J2EE. Yet the greatest shift is seen in the direction 

of heterogenous environments. Nearly 60% of 

respondents indicated different front-end 

environments from their preferred or anticipated 

back-end platforms. 

The increased reliance of XML for storing process 

definitions, the complete abstraction of the data 

management layer, and the growing leverage of 

Web services is starting to obviate the platform 

limitations which dominated just a few years. At 

this stage we firmly maintain that this is no single 

“right” platform choice, and that the pursuit of 

heterogeneous environments are a realistic goal. 

We have seen successful deployments co-mingle 

Windows infrastructure with J2EE applications. 

Examples include the integration of 

Windows-based SAP deployments with J2EE-based 

BPM servers, as well as the use of UNIX servers for 

transactional data and Windows or Web-based 

front-end environments. We have also seen cases 

where a premature “rush to J2EE” was apparent, 

and unnecessary in light of Windows-based 

options that also offer a reliable migration path to 

J2EE. This opportunity should be further 

enhanced by the maturing of .NET, which has 

recently started to affect BPM solution choices (by 

offering components within a Microsoft 

environment comparable to those seen with J2EE). 

J2EE/Web-only 

Web front-end, 

Microsoft back-end 

Microsoft front-end, 

J2EE back-end 

Web front-end, 

UNIX back-end 

Microsoft Only 

Anticipated Platform for 


16.8% 

16.8% 

15.0% 

26.9% 

24.5% 

0% 10% 20% 30% 40% 50% 

Respondents were asked to identify the 

anticipated platform for future BPM 

deployments. Where an app server(s) is 

expected to be used, respondents were 

asked to indicate which from the list 

presented below. What is most notable 

about the 2003 findings was the large 

percentage using open source options of 

JBoss or Oracle 9iAS (who licenses the 

Orion open source app server). 

IBM WebSphere 

BEA WebLogic 

Oracle 9iAS* 

JBoss* 

Sun ONE/iPlanet 

Other 

*Not Identified in the 2001 Survey 

App Server Choices for 


3.4% 

7.3% 

17.0% 

14.1% 

23.8% 

30.3% 

22.9% 

23.9% 

34.5% 

39.4% 

2003 Survey 

2001 Survey 

0% 10% 20% 30% 40% 50% 




BPM Standards 

22 

The Role of Standards in BPM 

If Samuel Clemens (a/k/a Mark Twain) were alive 

today, he might observe that "The nice thing about 

standards is that there are so many to chose from." 

The notion of a standard in software development 

implies as single method or specification, yet with 

every new market multiple "standards" always 

emerge. Over time these rearrange like soap 

bubbles on water, with overlapping specs merging 

into a single standard, while some specialized 

standards remain intact on their own. 

As firms first seek to push the market on their way, 

most new software segments initially see several 

redundant standards emerge. Yet the only real 

value in a standard is when the market picks one 

common approach, a process typically hastened by 

the support of "gorilla" vendors backing one 

standard and forcing competitors to follow suit. 

The BPM sector has seen a number of standards 

and specifications in its space. These include those 

from the Workflow Management Coalition, such as 

XPDL, Wf-XML and SWAP, to those designed for 

Web Services choreography (notably WSCI and 

BPEL), as well as the core Web services standards 

of SOAP, WSDL, and UDDI. Add to this a mix of 

public interface standards such as ICE, 

CommerceNet, RosettaNet, and OASIS’ ebXML BPSS 

(Business Process Specification Schema). 

It is this deluge of standards that many firms in a 

recent Delphi survey cited as their single greatest 

criticism of the software standards process, such 

that buyers (the most vote in a standards process) 

have not yet fully weighed-in on the BPM 

standards front. Yet another problem, as the 

findings below clearly illustrate, is that the 

market's awareness of BPM standards remains 

fairly low. Respondents were asked to rank their 

perceived value of the list of standards and 

consortia shown in the chart to the right. 

We admittedly mixed apples and oranges in this 

list, as Workflow Management Coalition (WfMC) is 

not a standard, but is responsible for a number of 

standards/specifications such as XPDL. The same 

is true for BPMI.org and BPML. UML 2.0 is not 

specific to BPM, but often shows in requirements 

documents for BPM (albeit not always advisedly). 

Yet rather than anointing any single standard, the 

goal of this exercise was to determine the market's 

attitudes towards the discrete set of standards and 

consortia most commonly associated with BPM. 

Findings were generally consistent with our own 

expectations. Standards in place the longest have 

the greatest perceived benefit, yet in general 

consortia such as the WfMC and BMPI.org still 

have a significant education burden in front of 

them before they are viewed as "must haves" 

among buyers. One surprise, however, was that 

for an audience so overwhelmingly predisposed 

to process management, both WfMC and BPEL 

ranked lower than we would have expected. 

In fairness to the WfMC, they received the highest 

vote of confidence from respondents. In most 

competitive bids Delphi Group has seen in the last 

12-18 months, membership in the WfMC is a very 

common requirement for BPM software suppliers. 

As such it was surprising to see the fine degree of 

differentiation among respondents’ rankings 

between this decade old organization and 

BPMI.org, who has been in place less than 3 years. 

It would be premature to announce the WfMC’s 

decline. Yet the close proximately of its rankings to 

BPMI undoubtedly will offer fodder to those 

pushing the notion of the younger consortia as the 

WfMC successor. This argument is largely rooted 

Workflow 

Management 

Coalition 

UML 2.0 

BPMI.org 

BPML 

RosettaNet 

BPEL 

XPDL 


Recognition of Existing BPM 

Standard Initiatives 

Greatest 

Importance 

Moderate 

Importance 

15% 58% 27% 

14% 60% 25% 

12% 54% 34% 

11% 49% 41% 

11% 64% 25% 

8% 43% 48% 

7% 40% 53% 

Little to 

No Importance 



BPM Standards 

23 

in the notion that BPMI is more contemporary in 

its focus and approach, while the WfMC is 

concerned more with earlier workflow 

management models. There is some merit to that 

argument, yet there is significant parallelism 

between their efforts. 

For most of its existence, the WfMC’s focus has 

been the development of five interfaces between 

application connection points, similar to what is 

illustrated in Figure 1 on page 6. These have 

evolved to incorporate the use of XML and other 

standards that have evolved over the last decade. 

The goal of BPMI has been largely the same -- 

to develop three specific standards (BPML, BPMN, 

and BPQL) which allow a common set of definition 

to interoperate across any compliant BPM system. 

In essence, to define the components of a 

“standard” BPMS based on the three constituent 

standards. Although the two sets of specifications 

are in many ways competitive, the two groups have 

collaborated on making them interoperable. 

Although it is certainly possible that both will 

continue to co-exist, a more likely scenario is that 

key specifications are extracted from the larger 

“stack”, such as WfMC’s XPDL co-existing with 

BPMI’s BPML (which is already under discussion 

by the two groups). Also shaping this is whether 

BPEL emerges as the winning standard for process 

execution, which seems likely will happen. 

Pronounced “bipple” it is officially named 

BPEL4WS or “business process execution language 

for Web services” but more popularly known as 

BPEL. BPEL v1.0 was initially submitted for public 

review by Microsoft, IBM and BEA Systems in 

August 2002, replacing the combined work of 

Microsoft's XLANG and IBM's WSFL. Following 

some concern within the market over large 

vendors dominating the specification, a coalition 

of vendors including IBM, Microsoft, BEA Systems, 

and SAP submitted BPEL v1.1 to the standards 

body OASIS in April of 2003. 

BPEL is declarative language for describing 

process definitions, meaning that it allows 

compliant process execution engines to run BPEL 

definitions as executable code. In this way it is 

similar in its design and intent to BPML, yet BPEL 

lacks some of former’s finer grain process syntax. 

This is an advantage for BPML today, however, it is 

by no means one that cannot be resolved over time 

as the specification evolves. 

In the case of BPEL and BPML, both lack the 

complexity of syntax to describe the full set of 

capabilities for every BPM solution. Both would 

need to further evolve to see market acceptance as 

a true standard among BPM vendors. 

This fact is evident in the initial coalition of 

vendors behind BPEL, who are application and 

infrastructure vendors (SAP, Microsft, BEA Systems, 

et al) and as such cannot design or support the 

more complex processes developed by BPM 

vendors. Since its acceptance by OASIS, however, 

BPM vendors already aligned with BPMI.org in 

what is more likely a legitimate move to align the 

two, rather than a matter of defection. 

While it is unlikely the buy-side of the market will 

support the continued existence of three sets of 

standards with BPEL, BPMI and XPDL, neither 

alone offer a complete set of specifications for 

adequately describing an entire BPM solution. 

Lacking in BPML, XPDL, and BPEL, for example, is 

a process modeling method capable of translating 

graphical models into executable process 

definitions. BPMI’s BPMN or “Business Process 

Modeling Notation” specification is designed for 

this purpose, to provide graphical notations for 

expressing business processes and is designed to 

translate these into BPML or (eventually) BPEL. 

As specifications evolve and converge, a likely 

shake-out will be the engulfing of BPML by BPEL. 

This leaves BPMN as a likely contender for the 

modeling requirements these two lack on their 

own. XDPL was designed as a process interchange 

standard and is currently used by some BPM 

vendors for storing process definitions. But it 

lacks a graphical notion outside of BPMN (which 

is currently being mapped to XPDL). The 

advantages of XDPL over BPEL will inevitably lead 

to advancements in the latter, with the likely longterm 

scenario (greater than 12 months) being the 

co-existence of BPMN and BPEL. 



Fuego Product Assessment 

24 

Product Assessment: Fuego 

Overview 

Incorporated as a US-based company in 1999, 

Fuego was one of the first commercial software 

vendors to differentiate BPM as a unique 

discipline, distinct from EAI and applicationcentric 

workflow. Fuego was arguably the first to 

promote the concept of services orchestration over 

discrete automation and integration. Fuego is a 

privately held firm that has raised $45 Million in 

venture capital since its founding. Fuego is a 

independent software vendor focused on a single 

application suite, Fuego (formerly FuegoBPM). 

Orientation and Positioning 

Fuego is a BPM solution focused on "business 

services orchestration" or more broadly stated, 

the ability to develop a virtual catalog of 

componentized services from new and existing 

applications, and to define executable business 

processes able to invoke these services, then 

manage the execution and lifecycles of both 

processes and components. Architecturally, Fuego 

is not a single packaged application but a set of 

development, execution and management 

resources composed of six core modules: 

1. Process Designer – GUI-based, drag-and-drop 

process development environment, used to map 

processes, define business rules and edit syntax. 

2. Component Manager – server-side 

resource for developing business 

objects and managing library of 

application service components, 

presentations and integration 

points. 

3. Orchestration Engine – run-time 

environment for executing 

processes, business rules, and 

invoked application. 

4. Work Portal – J2EE-compliant environment for 

managing Work Lists (e.g., the process end user 

environment). 

5. Process Analyzer – OLAP reporting and analysis 

tool for analyzing process performance metrics; 

two cubes are pre-built: Process Workload and 

Process Performance 

6. Organization Administrator – server-side 

manager of roles, organizational structure and 

calendars. 

These modules, as well as their role in BPM 

and services orchestration are described below. 

Process Modeling & Definition 

Processes are defined using the Fuego Process 

Designer, a GUI-based, drag-and-drop modeling 

environment with integrated scripting and 

debugging tools. Fuego presents a set of process 

design shapes that represent specific functionality 

(e.g., AUTOMATIC activity shape represents a 

process-to-system Activity; INTERACTIVE activity 

shape represents a process-to-human participant 

(GUI) Activity) but users can set preferences to use 

UML or user-defined icons with vertical or 

horizontal "swim lanes" used to identify roles that 

participate in a given process. 

Models can be developed using one set of shapes 

and "hot swapped" to another using a basic switch 

in the Process Designer model, or simultaneously 

developed in multiple modes by multiple 

designers. In this way, Process Designer is 

effectively methodology-agnostic in its visual 

metaphor. Process models are expressed in XML 

(using the XPDL schema) beneath the presentation 

layer, and compiled as executable Java code when 

published. 

Example Fuego Process Model 

Fuego’s process modeling tool technology 

partners, ProActivity and Proforma, have 

developed integration gateways which allow 

models in these environments to be translated into 

Fuego compliant models (specifically WfMC’s 

XPDL with Fuego Extensions). With existing 

models from these vendors, or UML models, there 

is insufficient syntax to define the level of service 




25 

interaction capability within Fuego. What they 

provide, however, is a means to leverage other 

process optimization initiatives or model designs. 

The third-party simulation and modeling tools 

also enable better integration of business concepts 

into the development process – by providing 

closed-loop reporting and analysis on process 

optimization. 

Fuego uses a Visual Basic like scripting language to 

define business rules for managing workflow, 

accessing, transforming and executing process 

objects, external applications, and data sources. 

Process Designer provides an IDE-type 

development environment for developing CIL 

instructions, and includes a syntax checker and an 

interactive debugger to test the business rules and 

services interactions. 

Process Designer supports collaborative design 

and development of process models and service 

interactions. This can be done hierarchically, with 

high-level flows designed by a business analyst 

and more granular service instructions developed 

by an application architect. This separation 

between business and technical functionality 

supports the objective of Fuego to enable 

processes to be defined by business users rather 

than programmers – a requirement reinforced by 

several data points in the survey detailed in this 

report. 

Development can also be done by a team of 

analysts simultaneously working on separate 

process elements. The security mechanism for 

controlling versions of subcomponents is handled 

by the LDAP security sign-in or with a third-party 

source code manager. Basic documentation is 

automatically generated and can be enhanced 

during process model definition in the Process 

Designer module. 

Process Execution 

Once defined within the Process Designer, 

processes are published as executable Java code to 

run and be managed by one or more of the Fuego 

Orchestration Engines. These Orchestration 

Engines provide the execution and management of 

all business process and business services accessed 

through the component manager (described later). 

Multiple Orchestration Engines can be deployed as 

a federation with a single engine designated to 

manage interaction between them. 

Communication between engines can be done via 

TCP/IP, as well as XML/SOAP over HTTP or HTTPS. 

Live Process Updates 

Live changes to process definitions or process 

parameters defined with the Fuego Organization 

Administrator (e.g., roles, calendars, etc) can be 

made on-the-fly without having to stop and restart 

a process instance. This enables the manner in 

which Fuego uses the notification mechanisms of 

an LDAP Server to poll for resources used by the 

Orchestration Engine when executing a process 

step. 

Fuego Work Portal 

Another point of separation between Fuego and 

alternative approaches for automation and 

integration is the ability to support manual 

activities and end-user participation. The Fuego 

Work Portal is the end user environment for 

engaging participants in process execution. The 

Work Portal generates unique work lists for each 

user. The Work Portal can be implemented to 

leverage LDAP or other directory services for user 

authentication, as well as extended to include 

external users (i.e., without named accounts) for 

B2B processes. The Work Portal can be assigned a 

URL for browser access or embedded in another 

web application. 

Another notable aspect of Fuego is the ability to 

define and maintain roles, organizational structure 

and calendars within the Fuego Organization 

Administrator. This can be used to enable rolebased 

routing of process objects, or combined with 

rules to enable escalation of process steps 

according to schedules and/or responsibilities. 

Process Integration 

What immediately differentiates Fuego from other 

process management approaches is the manner by 

which it enables application integration. Fuego 

employs a form of integration that is similar in 

approach to what is used by portal software 

vendors for building "portlets." Where it differs, 

however, is that the result contains not only 




26 

presentation logic (e.g., same as portlets), but also 

machine-readable instructions for how to invoke 

the component as an application service. 

Fuego's approach is distinct from the publish/ 

subscribe model common to message-oriented 

integration middleware. Rather than relying on 

EAI infrastructure, such as connectors and 

message brokering, Fuego instead relies on the 

ability to define rules using its scripting language 

to describe where and how to access data and 

application services, then wraps these into 

individual components that are exposed as 

consumable services to process designers. 

This is accomplished by introspecting metadata 

from an API (Application Programmer Interface) 

to determine the interface points of the application 

for which access is sought. Introspection is an 

aspect of componentization that presents a 

standard means of generating self-describing 

software components. In the simplest sense, 

introspection is analogous to the recipe and 

ingredients list on a box of cake mix (the former 

representing "cake metadata"). In a software 

context, it is the practice of providing metadata 

that describes how to invoke an application 

through its API. 

In essence, introspection allows one application to 

read another's interfaces and data structures, 

without requiring explicit knowledge of how that 

application was deployed. The use of introspection 

is found in applications and APIs developed in 

recent versions of Java (since the release of JDK 1.2 

and the introduction of Java Foundation Classes) 

and is inherent in Enterprise Java Beans (EJBs), as 

well as other component architectures such as 

CORBA and COM/DCOM. 

In application environments with limited 

introspection, such as SAP's BAPI (Business 

Application Programming Interface), Visual Basic 

can be used or create a COM wrapper, or where 

available, the SAP DCOM Object Builder can be 

used. Outside of SAP, various other tools are 

available to enable introspection, yet in virtually 

all cases the process of exposing metadata is far 

simpler than building application-to-application 

integration. In a case where customer adapters 

are already in place, these provide sufficient 

introspection and can also be used. An example 

of Fuego being used to orchestrate SAP application 

services is illustrated in the case study at the end 

of this section. 

With Fuego, scripts are used within the Process 

Designer to define the syntax for accessing 

applications. Once a component has been 

cataloged using introspection to determine the 

structure of data tables, available data variables, 

input parameters, and the specific pieces of data or 

application functionality needed, during the 

creation of the process model the process designer 

uses the component needed to product some result 

– i.e., display a User Interface, access a data record. 

An example might be "Get Invoice" and as such the 

scripts instructions define where to find an 

invoice, which input variables are needed 

("Customer #", etc), and how the invoice appears 

when received. Once the instructions are defined 

and encapsulated as a component, the component 

is cataloged within the Fuego Component Manager 

as a resource for the Fuego Process Designer and 

ultimately the Fuego Orchestration Engine. 

This cycle (building components) is an essential 

element of the Fuego eco-system and its 

significance should not be lost in the technical 

granularity of its description. In short, the Fuego 

Component Manager presents a universal access 

point for virtualizing data and applications into 

consumable services. The Fuego Orchestration 

Engine orchestrates the sequence in which these 

services are utilized or consumed. 

This illustrates the essence of service orchestration 

versus integration and automation. While 

integration and automation are by-products of this 

process, the Fuego approach (of directly accessing 

application services and data) allows for optimal 

use of existing automation, with minimal 

investment in integration. 

Leveraging Web Services 

The component-oriented modules of Fuego 

(notably the Component Manager) allow for 

applications to be virtualized into service 

components. The same capabilities extend to 




27 

pre-existing components, such as Web services 

with WSDL descriptors, COM/DCOM objects, EJBs, 

Java classes, CORBA, XML, SOAP messages, or 

other self-describing software. These can also be 

registered or "cataloged" with the Component 

Manager as executable services. The degree of 

autonomy and self-description dictates the amount 

of effort and scripting required registering them. 

But once cataloged, each component is a service 

available to any Fuego process with a single 

method of invocation. 

Fuego allows for integration logic (how to find and 

invoke data and applications) to be abstracted and 

managed separately from process logic (how these 

services are used). This approach is in contrast 

with more traditional pairings of process 

management and EAI, where specific integration 

points are defined but not otherwise exposed as 

services. Rather than building integration logic 

into the process, the Component Manager provides 

a single method for accessing data and 

functionality from a broad set of systems and 

application types. 

In this sense, the Component Manager is 

orthogonal to the message bus used in publish/ 

subscribe-type, message-oriented integration. 

Where these two part ways, however, is that the 

output of a message bus is meaningless to a 

process engine and serves only as a means for 

getting data from one point to another. 

In contrast, the Component Manager produces a 

result that is 100% consumable by the 

Orchestration Engine. Further, while the 

Component Manager is abstracted from the rest of 

the Fuego application modules, it is by design and 

definition far more tightly integrated than any 

third-party EAI software could be. It is looselycoupled 

with fine-grained interaction. 

Process Monitoring & Maintenance 

Executing Processes are managed by the 

Orchestration Engines. Inherent in the design of 

these engines are basic systems management 

capabilities, from back-up procedures and 

performance monitoring, to the ability to "listen" 

for execution problems and restart failed servers. 

A two-phase commit protocol is used to persist 

transactions and process state. In the event of 

failure, if the transaction was automated (e.g., an 

invoked application) it is rolled back to the 

previous state and restarted. If the transaction was 

a manual activity, the work item is sent back to the 

appropriate work list in the Work Portal. 

Fuego also provides a fail-safe mechanism through 

a system of one primary and multiple secondary 

Orchestration Engines. All Orchestration Engines 

are connected to one another notifying each other 

to check if they are active. If the primary 

Orchestration Engine stops working, one of the 

secondary Orchestration Engines will take the role 

of primary Orchestration Engine, managing the 

automatic and user generated transactions. 

Reporting 

Fuego Process Analyzer provides multidimensional 

OLAP reporting tools and analysis 

capabilities for analyzing process performance 

metrics captured by the Execution Engines. 

Extensions are provided for third-party report 

tools, such as Crystal Reports, however, there are 

comparatively sophisticated report design and 

analysis tools within Process Analyzer. Process 

Analyzer also allows for the creation of 

"dashboard" type live reports based on a discrete 

set of performance metrics. There are two 

predefined analysis cubes – Workload and Process 

Performance. 

Technology Platforms 

Fuego is a J2EE application framework requiring a 

Java Virtual Machine (JVM) to operate, as well as 

LDAP or SQL-compliant directory services, a Webserver 

(with a servlet container) or an application 

server, and a relational database. JVM (JDK 1.3 or 

higher) platforms supported including Windows 

NT or higher, as well as most major Unix variants 

(including Linux). 

Fuego supports any relational database with JDBC 

drivers, but already tested and verified are Oracle 

8i (Standard and Enterprise editions), Microsoft 

SQL Server (7.0 and higher), IBM DB2 (7.0 and 

higher), and Cloudscape. 



Tesoro Case Study 

28 

Standards Participation 

Fuego participates in various standards bodies and 

industry groups within the business process 

software space, including BPMI.org, ITAA, UDDI 

and RosettaNet. Both J2EE standards (JMS, JDBC, 

JNDI, JAAS, etc) and XML is used throughout the 

Fuego architecture, including process definitions 

that use the XPDL schema (the Workflow 

Management Coalition's XML Process Definition 

Language). Fuego is also exploring BPEL 

(discussed earlier in this report) as this 

specification evolves. 

Case Study: Tesoro Petroleum 

Highlights 

Orchestration of Existing Islands of Automation 

Distilling Complex Systems Into 

a Single Presentation Layer 

Reduced Training Requirements 

Improving the Accuracy, Timeliness, 

and Completeness of Data 

Improved Process Efficiency & Faster 

Inventory Turn-Over 

Cultural Shift From Packaged Software 

to Service Orchestration 

Deployment Environment 

Large-scale SAP deployment on Microsoft 

infrastructure. 

Case Study Overview 

Tesoro Petroleum is an $8 billion petroleum 

refining company in San Antonio, TX, using 

Fuego’s BPMS to address what Tesoro's CIO 

describes as the areas of "white space" across a 

major, multi-system SAP deployment. Tesoro 

estimates that close to 95% of its business runs on 

top of SAP. Fuego is used to acquire and post data 

to and from the SAP system, as well as to 

orchestrate user-centric processes that would be 

difficult (if not impossible) to define within SAP or 

through traditional EAI software. 

Problem Statement 

When the SAP system was built, Tesoro designed 

with a process-oriented architecture, rather than 

focusing on a single or set of software modules. 

This involved the development of a library of 

business scenarios and related documentation 

defining business processes. In this way, the SAP 

system covers the vast majority of the processes 

executed by Tesoro. What is left is the "white 

space" – the places in process requiring human 

intervention, as well as other disconnects between 

the flow of a business process and the specific 

application functions (i.e., SAP and other systems 

within a given process). Filling in this white space 

was the driver behind Tesoro's pursuit of a BPM 

solution. 

Tesoro's problem was not one of automation but 

orchestration. Automation was already achieved 

through its significant investment in SAP. The 

challenge for Tesoro was to bridge the complex 

and distributed islands of automation through 

orchestration of discrete transactions within endto-end 

processes. A cultural challenge for Tesoro, 

was that after being an SAP shop for many years 

it was necessary to develop an application 

development discipline consistent with building 

the reusable components required to leverage 

orchestration strategy, rather than focusing on the 

configuration of packaged software (as is the case 

with SAP). Related to this was the need to develop 

a business analysis competency required to define 

end-to-end processes with enough granularity and 

validation to handle the necessary hand-offs 

between applications and users. 

Product Evaluation Process 

Tesoro required process management system able 

to deliver on two objectives: 

1. Define end-to-end processes that complement 

and extend the processes and automation 

already built within SAP (e.g., filling in the 

white space), and 

2. Allow for granular, yet intuitive definition of 

business processes such that they can be 

understood and refined by non-IT, 

business-oriented personnel. 




29 

Tesoro began in 2001 with a survey of possible 

alternatives to address these issues. What they 

found, however, was that most options with the 

requisite integration capabilities were focused 

only on application-to-application transactions, 

and lacked the ability to define user-interfacing 

process steps. 

Consistent with the philosophy presented 

throughout this report, Tesoro understood the 

goal of BPM is to incorporate the people side 

of business processes with the application and 

systems side. Tesoro did look closely at leading 

integration platforms as a possible solution, but 

soon determined these were insufficient to 

address user-centric requirements. 

This led Tesoro to look beyond EAI solutions for 

an application that addressed the white space 

where individuals work outside of, or in concert, 

with other systems (rather than simply shuttling 

data between systems). Fuego was selected to 

create a process orchestration layer between users 

and systems. In this way Fuego provides the 

common presentation layer for users, then is able 

to parse-out and distribute pieces of a single user 

transaction and distributes the appropriate data to 

the three applications. 

Order-to-Cash 

Anything that has to do with inventory movements 

is a high priority for the oil refinery industry, and 

Tesoro is no exception to this. Oil is an expensive 

product to keep in inventory, and the goal of 

Tesoro is to move from the point of an order to the 

receipt of payment (read "cash") in the shortest 

time possible. 

This is what initially drove Tesoro to make such a 

sizable investment in SAP. Yet the inefficiencies 

remained at the points where discrete systems 

present hand-offs to users or other applications. 

Fuego is used to roll-up these discrete transactions 

across a given process (such as sales order entry) 

into a single transaction for SAP, ensuring the 

complete and most expedient entry of data, and 

negotiating the proper hand-offs between 

individual users. 

For any given sales transaction, the process 

involves creating a contract, then creating a sales 

order, then billing documents (payables and 

receivables), prior to payment. Across this process 

the same data needed to create a contract is 

required to be entered into three different systems 

(sales, goods, billing), which otherwise (prior to 

Fuego) requires three individuals to manually 

entered with each order. 

Areas of potential breakdown or inefficiency 

within this process include incomplete or 

erroneous data entered at any point, thus stalling 

the process or (worse) sending it back to be 

redone; inherent delays waiting for data to be 

entered; and the manual process of chasing down 

missing information. 

To resolve this, Tesoro built a portal interface with 

Fuego, which collects and validates all the 

information needed to complete a sales order, with 

each user seeing the environment appropriate for 

their own role, then rolls this up into a single 

transaction before it is posted to the appropriate 

SAP applications. 

Validation & Accuracy 

Service orchestration capabilities (such as those 

provide by Fuego) have opened the gates to far 

more and easier options for exposing and 

orchestration application functionality than was 

otherwise available with prior platform and EAI 

opportunities. 

Yet making use of these resources requires that 

the data driving these applications is precisely as 

is should be, or that the point of entry for data has 

the intelligence to resolve when this is not the case. 

Failing to resolve this presents a significant point 

of failure within any process management 

initiative. In Tesoro's case, it was determined that 

this difference represented 5 times the cost to 

make a correction to data within SAP than it does 

to enter it correctly the first time. 

Responding to the issues above, one of the first 

benefits Tesoro realized through its deployment 

of Fuego was to improve accuracy of both new 

and existing data posted to the SAP applications. 




About This Document: 

The product-specific 

information contained in this 

document is intended to 

provide an overview of a 

specific product and vendor at 

the date of publishing. Facts 

presented have been verified to 

the best of our ability with the 

vendor and actual users of the 

product where indicated, 

however, Delphi cannot insure 

the accuracy of this 

information since products, 

vendors, and market conditions 

change rapidly. Delphi Group 

makes no implied or explicit 

warranties, endorsements, or 

recommendations in this report 

nor should such warranties be 

inferred from its contents. A 

complete assessment of your 

specific application, the method 

of implementation for a given 

product or technology, and the 

current state of that product 

must be considered in order for 

a recommendation to be made 

on any product’s suitability for 

your purpose, needs and 

requirements. 

Delphi Group is a leading 

provider of business and 

technology advisory services to 

Global 2000 organizations. With 

offices established around the 

world, Delphi has assisted 

professionals across disciplines 

and industries at nearly every 

major national and global 

organization and branch of 

government. Its clients and 

subscribers include more than 

half of the Global 2000. 

Delphi Group 

Ten Post Office Square 

Boston, MA 02109-4603 

v (617) 247.1511 

f (617) 247.4957 

Within the front-end of the Fuego environment (presentation layer) 

Tesoro defined rules and validation procedures, which while transparent 

to the user, allowed greater over the quality and accuracy of data entered 

or updated within the system. 

As part of the same, completeness is also improved by validation that 

all information for a particular transaction is present, and if not Fuego 

invokes an activity to either obtain it from the appropriate system or 

prompts the user to update it. Timeliness is also improved as Fuego 

facilitates more on-line data entry, rather than relying on faxes and 

manual entry. 

Componentization and Orchestration 

Tesoro used the SAP BAPI structures wrapped with COM (Common 

Object Model) to enable introspection. This, Tesoro reports, required 

about one month's development time, with another month spent 

developing the Fuego components and process definitions to orchestrate 

the SAP application services. Tesoro also used Fuego to authenticate 

SAP users using Active Directory (the directory services used internally). 

During this process Fuego was also used to create a common presentation 

layer that masks the complexity of the underlying SAP systems. This single 

environment replaced multiple SAP screens, reducing training costs, error 

rates and overall intimation from had been at times a bewildering SAP 

environment. 

Of equal significance, however, was that the use of Fuego enabled Tesoro 

to make a major architectural shift without changing its underlying 

infrastructure. What had been a single application tier with multiple 

accessing points and interfaces, was transformed into a three-layer 

architecture: 

Presentation Layer – a single means for access all systems through the 

Fuego Work Portal 

Orchestration Layer – the execution of process, validation and posting 

of data, and orchestration of servers, accomplished by Fuego and 

transparent to users 

Application Layer – Existing SAP systems and Microsoft infrastructure 

This presents an extensible infrastructure for deploying new processes 

and orchestrating additional services, without having to alter the user 

environment or back-end infrastructure. Looking forward, Tesoro is 

examining how they can address issues such as Sarbanes-Oxley 

Compliance with the Fuego BPMS. The incremental approach enabled by 

Fuego will allow for existing work to be leveraged in this process, such as 

monitoring SAP transactions for possible compliance violations. 

www.delphigroup.com

BPM WP FileNET

Create successful ePaper yourself

Delete template?

Save as template?