A BPTrends Report

BPM Product

Report

Introduction and

Overview

Paul Harmon

www.bptrends.com

Contents

Foreword by Celia Wolf ………………………………………………………………………….1

The BPM Decade ……………………………………………………………………….……….3

The Evolving Architecture of the BPMS Platform ……………………………...……………..9

The Need for BPMS Software in the Future ………………………….................................. 14

Moore’s Technology Lifecycle and BPM ……………………………...……………….……. 17

1

Foreword

Beginning in 2005 BPTrends published our BPM Software Products Reports describing some of the BPM software products that were popular at that time. This year (2010) we are revising the BPTrends BPM Software Products Reports, updating the current reports, incorporating the changes resulting from the many mergers and acquisitions that have occurred and adding new vendors we have identified.

We categorized the BPM software products and are publishing the following three reports: The BPM Enterprise Architecture, Process Modeling and Simulation Tools Report, The BPM Suites Report, and The Rules Report. In each report we define the specific market, describe the features important in tools designed for that market and provide detailed reviews of the leading players and their products,

Our objective is to present the various options within the BPM software market - not to choose or rank the “best” BPM products. Thus, unlike Gartner that has an extensive “features” list, we have a set of core criteria. All features that extend beyond the core will be treated as extensions of the core that render the tool more useful for the development of specific types of process work or for the development of BPM applications. We focus on positioning each product in terms of its unique capabilities and primary strengths.

The market for BPM software products has changed significantly since 2005 and this update reflects that change. Increasingly, individual products are combining functions and can serve more than one purpose. To reflect this change we are publishing a single, general overview of the BPM software tools market, followed by the vendor product reports in one or more of 3 basic BPM Software product categories. The overview defines how companies use software to support their BPM efforts and identifies the functions the individual products support.

Initially, we define the following 3 basic product categories:

� Enterprise, Modeling and Simulation Tools

� Business Rule Management Tools

� Comprehensive BPM Suites or Platforms

We recognize that the market is evolving and that different companies have different strategies. For example, some BPM software products focus on managing processes that are largely manual, while others specialize in managing processes that are entirely, or almost entirely, automated. Similarly, some BPM software products focus on facilitating the internal integration of packaged applications, while others are tailored to better facilitate applications distributed in service-oriented Web environments.

Participating Vendors

BPTrends solicited the participation of the BPM software vendors we could identify at a modest cost to cover the expense of producing the reports. All products from participating vendors were evaluated in the same manner: BPTrends prepared a detailed questionnaire that each vendor was asked to complete. We reviewed the vendor questionnaires, and other relevant materials provided by the vendors, and edited and produced the final reports. We did not do any product testing.

We will maintain and expand the report going forward and any vendors that would like to be included should contact Carolyn Potts, at capotts@bptrends.com.

2

Thanks to Our Coauthors and Members

I want to thank my longtime friend and business partner, Paul Harmon, for bringing his vision, knowledge, and perspective on the business process performance market to bear on this report and Carolyn Potts for her editorial and production contributions. And, I want to thank all the current and future participating vendors for their cooperation. Finally, I want to thank all our BPTrends members and readers who continue to support us. We hope this report is informative and useful to all of you.

Celia Wolf Founder, CEO and Publisher Business Process Trends cwolf@bptrends.com

3

The Business Process Management Decade

To understand where Business Process Management software is today, you need to understand where it all came from. Figure 1 provides a simple overview of the recent evolution of the BPMS software market, which began, for all practical purposes, with the publication of the book: Business Process Management: The Third Wave, by Howard Smith and Peter Fingar, and the first meetings of the Business Process Management Initiative (BPMI) in 2003.

1980 1990 2000 2010

CASE

Expert Systems

Process Modeling Tools

Enterprise Resource Planning

Workflow

OMG BPMN

Standard

Smith & Finger, BPM,

HarmonBP Change

OASIS BEPL

Standard

Internet/Web/XML

Client Server

Computing

Service Oriented

ArchitecturePersonal Computer

Consolidation of BPMS Market

ERPVendor BPMS

Decision Centric BPMS

EmergingBPMS

Platform

Business Rule Mang. Software

Business Intelligence & Data Mining

Hammer & Champy

ReengineeringCorp.

Six Sigma Motorola

Rummler-BracheImprovingPerformance

Ent. Application Integ. Software

Workflow Centric BPMS

EAICentric BPMS

Burlton, BPM

Figure 1. The evolution of BPM software products.

The term “Business Process Management” had been in use well before 2003, was very much in the mainstream of business process work, and had usually been used to refer to efforts to better manage process change efforts within organizations. BPM, as used in the title of Roger Burlton’s 2001 book of the same name, for example, described an approach to process management and a process improvement methodology, but had little to do with software.

In 2003, however, Smith and Fingar and BPMI gave the term a new twist. Smith and Fingars’ book and BPMI both argued that the Web, and XML in particular, would make it possible to integrate software technologies that had previously been separate and to create a powerful new class of tools that would allow organizations to create BPM software applications that would dynamically manage the execution of business processes. Workflow tools had been used to create workflow applications that functioned in this manner in the late Nineties. The best workflow applications allowed organizations to scan documents into a repository, and then rely on a workflow application to send digital copies of each specific document to the computers of the employees who needed to participate in the processing of the documents.

In a similar way, the use of Enterprise Resource Planning (ERP) applications led many organizations to acquire Enterprise Application Integration (EAI) software. In effect each ERP vendor sold

4

applications that were difficult to integrate with older legacy applications or with other ERP applications sold by other ERP vendors. This caused considerable frustration, and companies sought tools that could “sit on top” of their various ERP and legacy applications and manage the movement of data from one application to the next.

Most workflow tools and some EAI tools relied on process modeling tools to provide developers and managers with an interface into the tool. In essence, a workflow team could create a process flow diagram that conformed to formal semantics and that would then generate the software program that guided the flow of documents from one workstation to the next. Similarly, an appropriate diagram could become the basis for an EAI application, specifying that data from one software application should be reformatted in some particular manner and then passed to another software application.

What Smith, Fingar and the founders of BPMI all realized was that by early 2000 it was possible to integrate all these technologies by using XML, a popular web data manipulation language. Moreover, by combining workflow and EA, it was possible to create applications that could manage almost any kind of business process that a company might want to automate.

There were a few BPMS tools built in the early years of the 2000’s that tried to implement an integrated model of workflow and EAI. In most cases, however, vendors who were already selling workflow tools launched new versions of their workflow products and called them BPM software tools. Similarly, several EAI vendors rushed out new versions of their products and also termed their new versions BPMS products.

In a similar way, several software vendors who were selling business rule management tools offered new versions of their products and termed their offerings BPM software packages. This was the situation in early 2004-05 when we developed our first reports on the BPM software market.

In a reasonably short time the ERP vendors began to enter the fray, and began to create their own BPMS products which they positioned as a way to organize and manage their ERP applications as business processes. Thus by the mid-2000-2010 decade SAP was building BPM capabilities into NetWeaver, and Oracle was talking about its BPEL product.

Each of the new BPMS vendors was better at some things and worse at others. If a vendor came from the workflow tradition, they were good at building applications to manage human tasks and document flows, and usually not so strong at handling EAI types of tasks. Similarly, the EAI vendors who began offering BPMS products were good at managing ERP applications and integrating software applications to support a process flow, but less capable of handling workflow and document management.

In almost all cases, the early BPMS vendors lacked really good process modeling environments. Most of the process modeling vendors that were available in the early 2000’s came from the Computer Aided Software Engineering (CASE) tradition that had flourished at the very end of the Eighties and largely died in the early Nineties, when most companies began to shift from mainframes to client server-based systems. Most of the CASE vendors that survived either specialized in helping software developers model their applications, or they shifted, learned more about business process reengineering and offered software modeling environments for Six Sigma practitioners and Business Analysts. Both types of vendors repositioned themselves and called themselves Business Process Modeling tool vendors. A good example of the former is IDS Scheer’s ARIS which specialized in helping software developers design SAP applications. The latter, including vendors like ProForma, Casewise, and MEGA, developed very good user interfaces that business people could use. Business users who were familiar with the better Process Modeling environments found the early workflow and EAI derived BPMS tools – which were all originally designed for software developers -- difficult to use.

5

This situation touched off the beginning of the BPMS consolidation that has been gaining momentum since the middle of the 2000-2010decade. First, workflow and EAI vendors acquired Process Modeling tool vendors to gain better interfaces and more knowledge about how business people actually approach process redesign and management.

Market analysts started classifying BPMS tools as people-centric, software-centric, and decision-centric. This stimulated further consolidation, as vendors acquired products with technologies to extend their capabilities. Thus, former EAI vendors bought former workflow vendors, and vice-versa. Initially most of the new BPMS players seemed content to lease a business rule management engine from someone else and simply include it into their BPMS offering, but as the first decade of the 2000’s ended, the leading BPMS vendors began to buy the rules management vendors.

The Rules Management products were mostly tools that had been developed for the Artificial Intelligence (AI) and Expert Systems boom of the mid-Eighties. When the interest in Expert Systems begin to fade at the beginning of the Nineties the expert system tool vendors began to reposition themselves as Business Rules Management tools and, in the process, simplified their tools. Expert System tools were designed to help developers capture information that resided in the heads of human experts. Business Rules, on the other hand, were usually derived from company policies or from business documentation. The acquisition and organization of business rules was, generally, less complex than the acquisition of human knowledge. Moreover, it changed less often and was easier to maintain.

At the same time that the Expert Systems vendors began to reposition themselves as Business Rule Management tools, others in the AI and expert systems tradition began to apply their techniques to mining databases for patterns that could help guide business decisions. These companies tended to call themselves Business Intelligence (BI) vendors and often referred to their approach as Data Mining. A number of BI or Data Mining vendors arose in the 90’s and were used in conjunction with Data Warehouses to help companies analyze their data in a search for information and insights that could guide business decisions. This whole field, today, is often referred to as Analytics, or more simply, Decision Support.

By 2007, the leading BPMS products represented a combination of workflow, EAI, and process modeling, typically created by one or two acquisitions. A brief list of some of the acquisitions is shown in Table 1.

The Business Process Management Notation (BPMN) standard, originally developed by the BPMI group – which subsequently merged with the Object Management Group (OMG) – has become extremely popular and most BPMS vendors now offer support for this reasonably straightforward way of diagramming processes. The BPMN standard has a core notation that business managers can use and a much more detailed notation that software developers can use to generate a diagram that can, in turn, generate software code.

The Business Process Execution Language (BPEL) was originally proposed by IBM and Microsoft, and was then submitted to OASIS for official standardization. BPEL is a language that describes processes in a formal syntax which can be converted into executable code. A popular idea has been to use BPMN to generate BPEL. This idea was especially popular in the early years of BPMS, but has, to date, proved difficult to realize. The OASIS standards team has yet to release a new version of BPEL that will fully support both workflow and EAI concerns. (BPEL is better at generating processes that manage EAI than processes that involve employees and documents.) Enthusiasm for BPEL seems to be declining.

As the first decade of the 2000 drew to a close the consolidation of the BPM market increased and leading BPM vendors turned their attention to Business Rule Management products and to BI and Data Mining products. Rules management technologies complemented EAI and workflow techniques. BI and Data Mining technologies, on the other hand, were acquired to provide users

6

with better ways of summarizing data and creating dashboards for managers who wanted to manage the execution of business processes.

In addition, toward the end of the decade some vendors began to use a variation on Data Mining techniques to analyze process patterns using data that was stored in databases as the processes were executed. Several BPMS products offer Process Mining capabilities. In essence, process mining looks at existing databases that support existing business processes and then generates diagrams that show how data is flowing to and from the process-in-scope. Using this technique, a manager can better understand the nature of an existing business process and gain insight into changes that would simplify the flow.

If all this complexity were not enough, in the late 00’s, most large BPMS vendors began to promote the idea of a Service Oriented Architecture (SOA) as a better way to manage infrastructure technologies. In BPM terms, this meant that the software modules that business activities called upon were conceptualized as Services. As the leading BPMS vendors began to adopt SOA they began to redesign their BPMS packages to run in SOA environments. As if this were not enough, recently some of the BPMS vendors have begun to explore Cloud Computing and are exploring how a company might develop and manage a business process whose BPMS engine resided on some

7

server that could only be accessed dynamically by means of the Web. Cloud Computing is only beginning to catch on, but it suggests that the BPMS platform has yet to assume its final configuration, and that, in the meantime, companies will need to continue to struggle to determine exactly what a BPMS package should include.

If BPMS has not been more widely adopted during the past decade, at least one of the reasons is that BPMS has been a moving target. The competition has been fierce. When we did our first BPMS report in 2005 we estimated there were 50-100 vendors offering products that could be broadly construed as BPMS products. Today, in spite of considerable consolidation, there are still over 50 vendors offering BPMS products. At the same time, the number of technologies available in a large, comprehensive BPMS product has grown considerably. The time it now takes for a business manager who is considering an acquisition to learn about the technological options available in BPMS products has grown accordingly.

As 2010 begins we have a two tier market. The top tier is dominated by major software platform vendors who have been the primary acquirers of other BPMS vendors over the past five years. These vendors now speak in terms of BPMS platforms – of a suite of software technologies that could support any and all process initiatives that a large corporation might consider. The existing products may not quite match the vision, but the best of the BPMS platforms offer very comprehensive support for process work. It’s true that most of the BPMS platforms have yet to be well integrated. Too many acquisitions have occurred too quickly, and today’s large BPMS offerings are often loosely bundled sets of products that were developed using more or less incompatible underlying technologies. It will probably be another five years before the existing BPMS platforms are tightly integrated behind intuitive interfaces, but that is clearly the direction in which the leading BPMS platform vendors are heading.

The second tier of the market is still dominated by smaller, more specialized vendors. Many are startups and are exploring new areas of process functionality. We fully expect that some of the BPMS vendors who aren’t acquired will specialize in particular industry niches, but that hasn’t occurred yet. The major acquisitions have probably taken place but we fully expect to see new vendors coming on the scene and further acquisitions through the course of the next few years.

Returning to where we began, Smith and Fingar and the BPMI kicked off the current interest in BPMS products by suggesting that the new Web technologies available would allow companies to build business process management systems that would let business managers control their own processes. To date, most BPMS applications have been created by software developers or at least by business analysts. Considering that the leading BPMS products are, in essence, based on decade-old EAI and workflow platforms that were developed for programmers, this isn’t very surprising. The initial BPMS products didn’t have interfaces that would easily support their use by business managers. Some of the tools have become better, but, at the same time, all the tool vendors were continually incorporating new software technologies, like Business Rules, Data Mining, and SOA, which have made the products much harder to understand or use. The BPMS platform that exists today is not something that most business managers find comprehensible. At their best, these BPMS platforms will be used by Business Analysts and BPMS specialists. In most cases they will remain process-oriented software development environments.

A few smaller vendors have struggled to keep the idea of manager-controlled BPMS environments alive. They are, today, smaller tools, mostly derived from the workflow tradition. We suspect that the larger BPMS platforms will dominate the market in the near future and will be used by BPMS specialists and software developers. At the same time, however, we suspect that a smaller set of BPMS environments will continue to thrive by offering business managers with a way to create and control their own business process management applications. These manager-friendly tools will not be the tools that a company would want to use to build a worldwide supply chain management system. On the other hand, they may well be the tools preferred for defining and managing very

8

dynamic processes – processes that are being changed frequently, that rely on rapidly evolving knowledge, and that depend on the collaboration of several employees. (See Figure 2.)

Figure 2. Three different niches in the BPMS market

We expect that the BPMS software market will get even more interesting in the years ahead. The products of the major BPMS vendors will become more polished and they will be used by large companies. Those adoptions, and a growing number of interesting applications will convince other companies to explore the possibilities. Some will acquire the large generic BPMS tools offered by major platform vendors. Others, however, will be more interested in industry specific BPMS products or in the newer, manager friendly products available from the more innovative, smaller vendors.

9

The Evolving Architecture of the BPMS Platform

Let’s consider the evolving BPMS Platform in a little more detail. Before that, however, let’s be sure we understand the difference between a BPMS Platform and a BPMS application.

A Business Process Management System Platform (BPMS Platform) is a suite of software tools and utilities that are used to create BPMS applications. A specific application is created by using the BPMS Platform to organize and control specific knowledge about a particular process. Most of the utilities in the platform must be embedded in each finished application, because it is the engines in the platform that actually assemble and use the specific process knowledge at runtime. The specific knowledge may include process flow diagrams, business rules, and software applications used by the process, as well as the location of employee computers that will be involved in executing the process. It may also include knowledge of measurement criteria and information about where to send the resulting performance data. In other words a BPMS Platform is used to create a BPMS Application and a BPMS Application is used to manage the ongoing execution of a specific, real business process. In addition the BPMS tool allows managers or software developers to quickly alter existing BPMS applications by making adjustments in the flow or measurement of the runtime processes in question.

Figure 3 provides a very high level overview of the relationship between a BPMS platform and a BPMS application.

Figure 1. An organization adds knowledge to a BPMS platform to create a BPMS

application

In Figure 3 we represent the entire BPM Application as a single box. In Figure 4 we provide a more detailed look at the architectural elements that might make up a specific BPMS platform. The BPMS Platform combines a variety of tools and engines to provide a BPM group with all of the functionality they need to handle process change at their organization.

At the top we show a box representing the complete BPMS Platform or package. We show it connected to a Process Repository. At the moment many vendors simply use a database and organize the information in the database to conform with the tools and utilities included in the BPMS Platform. In the long run, large organizations will probably insist on a standard, independent process repository so that they can easily use multiple BPMS Platforms or shift between platforms without losing their investment in BPM development.

Turning to the specific layers that make up the BPMS Platform, and working from the top layer down we encounter BPM Tools, BPM Engines or Servers, Programming Interfaces/Tools and Language or Middleware. We’ll consider the elements of each, in turn.

10

Figure 2. A Business Process Management Software Platform

BPM Tools

Below the BPM Suite are various Tools or Utilities that can either be stand-alone products, or tightly integrated elements in a BPM Suite. We divide this area into two. The BPM Software Tools, including Process Modeling tools, Process Monitoring tools, Business Rule Management tools and Software Performance tools. We usually include technologies like BI and process mining in the monitoring/BI environments, and include tools that can be used to evaluate the performance of specific software applications being used by the process under Software Performance.

Process Modeling Environments provide users with a way of diagramming the flow of the application that is being created. The tools may include simple diagramming tools for business people, but they must also include a diagramming environment that allows users to specify the flow of the application in enough detail so that a software engine can interpret the diagram and take specific actions. One common approach is to divide the effort and specify the flow with a diagram and then specify how decisions are made by defining specific business rules to be applied to make each decision.

There are several Process Modeling Vendors selling stand-alone tools and some of the platform vendors sell their process modeling tools in stand-alone versions. This is important because most business process redesign work is done by business teams without any thought of automating the process. Instead, the process team is simply interested in defining how the process is done, and perhaps redesigning the process to make it work better.

Enterprise Modeling Environments provide users with an overview of the organization. They may include models of organizational goals and missions, but they also provide ways of examining how all the processes in the organization relate to one another and to elements outside the organization. This type of capability is usually included in the more sophisticated Process Modeling Tools, but it may also be included in a standalone tool, specialized for enterprise modeling.

There is no agreed upon way of modeling enterprise environments, so these tools vary quite a bit in their approach. Most of the activity in this area is with startup companies trying to create the first really popular enterprise modeling tool.

Process Monitoring/BI Environments provide users with ways of gathering and summarizing data about the ongoing operation of processes. All of the early BPMS products

11

provided some way of capturing information about the execution of a process and relaying that information to supervisors. Thus, most tools would monitor the flow of data through a document handling process and be able to report that agent 1 processed 50 documents in a day, while agent 2 processed 43, etc. This information was useful to the manager immediately responsible for the process, but was too detailed for senior managers. As BPMS vendors sought to provide a more comprehensive tool, they began to acquire dashboard technology so they could present a graphic picture of a whole range of key performance indicators. As the competition continued, the leading BPMS vendors forged relationships with Business Intelligence (BI) or Data Monitoring vendors and combined data from process execution with other data in their organizational databases (e.g. data on customer satisfaction surveys, returns, complaints, etc.) which the BI tools summarized and analyzed for patterns. Today, the best BPMS tools can provide senior managers not only with information about specific process events, but can track process trends, note problems and make suggestions for dealing with problems.

Some vendors have incorporated Process Mining capabilities into their tools. Process Mining is a variation on data mining that looks at the events that occur during processing (e.g. the data generated by interactions between a process and a database) and provides a map of how the instances of a process flow. This kind of data may reveal interesting patterns. For example, the fact that instances of a particular process commonly flow from Activity 1 to Activity 5 and are then returned to Activity 4 suggests a problem. Either Activity 4 is passing things to Activity 5 that are not complete, or Activity 4 and Activity 5 have different criteria or rules for processing the items in question. In either case, the Process Mining tool has highlighted a process problem for investigation. As time passes we are going to see BPMS products with more automated tools of this kind to help focus process managers on areas that need attention.

Business Rules Management Tools provide a way of documenting and automating decisions. At a minimum a Business Rules tool can be used to record business rules and keep track of which activities use which rules. When the Business Rules Tool uses a rules engine, the tool can actually examine rules in response to process events and make decisions about how the process should proceed. Using this approach, a customer can provide information about a desired car loan and the business rules system can check account balances, credit history, and so forth and then apply a set of some 200 rules to decide whether or not to grant the auto loan.

There are still a number of independent business rule vendors. They very widely from tools that are very technical and designed for managing rules for detecting fraud or controlling a chemical plant to simpler tools with spreadsheet-like interfaces that business managers can use to define when premium customers should be given discounts. Having independent rule tools is appropriate as many companies still have completely independent business rules groups and process redesign groups and do not think of the technologies as related. Increasingly, however, the two technologies are being integrated and the leading BPMS vendors have bought business rules vendors to further that integration in their BPMS platforms.

Software Performance Tools provide a way of determining the technical interactions between a BPMS product and the software applications it manages. Thus, for example, a process may call several ERP applications for support during the course of executing an instance of a process. If the overall execution time slows, BPMS specialists or software developers may wish to examine input and output data for each ERP application to identify where the slowdown has occurred. Although rather technical, these tools can provide powerful support when the process in focus is an EAI-heavy process that is managing many complex ERP or legacy applications.

As a broad generalization, most software performance tools are sold by OS or platform vendors and used independent of process management work. Still, the integration of such tools into BPMS applications provides a significant convenient tool for process managers working with EAI-oriented processes.

12

BPM Servers and Engines

Below the Tools or Utilities, we list BPM Servers or Engines. These can also be sold as either stand-alone products or as elements in a BPM Suite. In essence, an engine is an interpreter and it is imbedded in any application generated by the BPMS platform. When you analyze a process and generate a series of business rules to be used when the process is executed, the rules you generate are more or less independent of the application, which makes them easy to change. On the other hand, rule independence is bought by embedding a rule engine that actually processes the rules, at runtime, when the application is executed. Let’s consider the different types of engines your BPMS environment might have.

Workflow engines, as the term is used in BPMS, suggests an engine that interprets a process flow diagram and sends data from employee workstations to databases as defined by the flow diagram. The workflow engine is the key to building a process management application that will organize, control and monitor the work of employees during the execution of a process instance. The workflow engine moves data from workstations, obtaining employee approvals, allowing applications to be check, handling rejections and sending out acceptance letters, etc. Vendors that started life with workflow products have emphasized the human side of business process work, and have tended to acquire EAI vendors to supplement their human emphasis.

Some BPMS products are still, today, primarily based on workflow engines. This emphasis is especially popular with vendors who seek to involve managers in the development and control of processes applications.

Enterprise Application Integration (EAI) engines move data from one software application to another. In many cases BPMS products lean very heavily on operating systems and Internet protocols to handle much of this, but all bring something to handling software processing. The emphasis here is on managing other software applications that are called as a process is executed. In essence the BPMS platform formats that data and passes it to a software engine, obtains results and then passes that data, reformatted as necessary to a user or to another software application. The emphasis on tools specializing in EAI should be flexibility, speed and ability to scale.

Some BPMS products are still primarily based on EAI engines, although this approach was most popular with the major OS/software platform vendors (IBM, Oracle, SAP) and they have been very active in acquiring smaller workflow vendors to round out their offering. In other words, most of the BPMS platform vendors have a strong EAI base and have added other engines to that core.

Business Rule Management engines provide a specific rule interpreter that sorts and links business rules as the application is being executed. This is a bit simple as most have an intermediate stage where they compile a search tree, but the emphasis is on keeping the specific rules independent of the engine that examines the rules at runtime. This is done to assure that users can quickly change rules as needed. Most of these tools provide various utilities that allow the developer to specify the attributes and values that are used in rules and to organize rule sets. Since most rules are used in more than one activity or process, one usually wants to store and manage rules indepdent of the process flow. In other words, when a given process requires rules to make a decision, the process flow engine ought to call the rule engine, which then examines the rule base and passes the decision back to the process engine.

Initially most of the BPMS vendors were content to “lease and embed” rule engines in their tools. Thus there were BPMS tools with rule engines and Business Rule Management Vendors who provided the actual rule environments that were embedded in the BPMS tools. At the same time there were some rule vendors that didn’t consider themselves BPMS players, but never-the-less offered Business Rule Management products which they sold directly to end users. Recently the

13

leading BPMS vendors have changed their approach and several of the Business Rule Management vendors have been acquired by BPMS vendors and integrated into their BPMS platforms.

We consider the rule capabilities of BPMS products, and we also have separate reports to describe those BRM vendors that are still operating as independent vendors.

Programming Interfaces and Tools

To the left in Figure 4, we show two interfaces that are required to allow people to use the tools. Some tools may provide many additional interfaces, especially if the tools or engines are poorly integrated. In all cases, however, one interface is required to allow developers to enter information into the tool to create an application. At a minimum such an interface will allow the developer to define a process flow, define rules and points where data will be gathered. It will allow the users to specify employees who will be sent information at different points in the flow and it will specify when software applications will be called, what data will be sent to applications when they are called, and so forth.

A second interface is required to let people monitor the runtime execution of a process. In essence this interface allows managers to see what happens as specific instances of the application are processed. This interface may include elaborate executive dashboards that make it possible for senior managers to maintain a continuous awareness of the ongoing execution of the process. This same interface may allow process managers to make specific changes in the runtime process to change how subsequent instances are handled.

In many cases platform vendors with tools originally designed for software developers have acquired process modeling or dashboard vendors to gain access to code that will allow them to offer better interfaces for business managers. In almost all cases the programming interfaces are a part of the BPMS product and we have never analyzed any stand-alone Programming Interface vendors.

Languages and Middleware Architectures

BPM Suites, Tools, Utilities, Servers and Engines all rest on a Language Platform or Architecture and we have listed some of the most common at the bottom of Figure 4. One major distinction is between BPMS products designed to run in Microsoft Windows environments that rely on Microsoft NET/Biztalk technology and those designed to run on other operating systems and designed to operate on Java J2EE technology. Separately, there are considerations of how the BPMS product handles access to other software modules. Most have an internal, OS or proprietary way of handling application access, but a growing number are shifting to SOA approaches. Almost all of the BPMS products rely on the Internet and Web to access and distribute information and use XML to pass data. Some tools generate BPEL code to define workflow or interfaces, but as BPEL is not a complete language, at this point, all supplement BPEL with other code making their applications more or less proprietary, in spite of claims to the contrary. Do not plan to move a BPMS application built in one tool to another tool without some reprogramming. This capability may come, but it will be several years before it can be done without some reprogramming.

.

14

The Need for BPM Software in the Future

Still another way to think about the evolving BPM software market is to consider the current maturity of most companies using BPM software and to ask how changes in maturity will affect software demand.

CMMI Maturity Levels

The concept of Process Maturity Levels was developed at the Software Engineering Institute (SEI) at Carnegie Mellon University in the Nineties, based on quality work originally undertaken by Watts Humphrey. Originally developed to support the analysis of software process maturity (CMM), the latest version, the Capability Maturity Model Integrated (CMMI) has been generalized so that it can be applied to any of a wide variety of processes in diverse organizations. (See Figure 1.)

Figure 1. An Overview of the basic CMMI maturity levels

Software organizations often pay SEI certified evaluators to do a formal evaluation to determine where their organizations are on the CMMI scale. Many other companies do informal evaluations, based on the broad concepts inherent in the CMMI “stair step diagram.” What follows is an informal description of the CMMI process maturity model.

Level 1. No Organized Processes. Level 1 organizations don’t rely on processes. Things get done according to plans made on the fly. CMMI folks often refer to them as organizations based on heroes. Things get done because someone makes a heroic effort and gets the report out at the last minute. If someone asks how long something will take, or what resources will be needed, those answering the question are just making a guess – they don’t have a systematic procedure or the data needed to provide accurate answers to these questions.

Level 2. Some Organized Processes. When organizations first began to embrace processes, they begin by trying to define their core or most commonly used processes. At this stage, they don’t conceptualize the entire company as a set of processes, all interrelated, but focus only on a specific process as it functions within some more or less arbitrary set of boundaries. Level 2 Organizations have several of their major processes defined.

15

Level 3. Most Processes Organized. Level 3 organizations have most of their processes defined. They not only have models of their core business processes, but understand how management and support processes work to support those processes. Most Level 3 organizations have a process architecture that shows how all of the organizations in the company function. Thus, if there is a problem, it’s easy to quickly identify the processes that could be causing the problem and the implications for any suggested change.

Level 4. Processes Are Managed. Level 4 organizations have gone well beyond simply defining all their processes. These organizations have process managers who gather data on process performance and customer satisfaction and use this data to make decisions about how to optimize the processes they manage.

Level 5. Processes Are Continuously Improved. Level 5 organizations have built processes right into the essence of the organization. They know their processes and manage their processes. Moreover, they have systems in place to constantly improve their processes whenever possible.

Most organizations are not, of course, right at one level or another. Studies have suggested that most organizations in the US are somewhere between Level 2 and Level 3, trying to expand the processes they have modeled and understand into a complete process architecture. Similarly, a smaller group of companies are between Levels 3 and 4. They are working to establish process management and measurement systems throughout the company.

In large organizations, it is common to find that one division or group will be at a different level of maturity than other groups or divisions within the same organization.

Maturity and Software Product Use

We have no detailed evidence, but we have worked with lots of companies undertaking enterprise and process redesign work and we have the strong impression that organizations at different levels of maturity use different software tools. Figure 2 places the maturity steps on the vertical axis and uses circles to suggest where most companies are today. This is a very impressionist diagram, but the data suggests that most companies are at level 2 or just beginning to explore level 3.

Level 1. No Organized

Processes

Level 2. Some

Organized Processes

Level 3. Most

Processes Organized

Level 4. Processes Are

Managed

Level 5. Processes

Continuously Improved

Organizations

BPMS Suites or Platforms

Repository Based Process Modeling Tools

Simple Modeling Tools

Business Rules Tools

Process Monitoring/BI Tools

Enterprise Modeling Tools

About Where Most Organizations Are Today

Figure 2. Maturity, Where Companies Are, and the Products They Need

Companies that aren’t interested in process, or don’t know what their processes are have no use for process tools. As they begin to move up the maturity scale and work to define their departmental processes they quickly develop a need for process modeling software. If the organizations are rule-oriented, as government and insurance organizations typically are, they may prefer business rule tools to help in the documentation and organization of their business rules.

16

A significant change takes place somewhere between Levels 2 and 3 as those in charge of process work realize that they have been using graphic modeling tools (e.g. Visio) and that they have not accumulated the knowledge form previous process projects. At this point there is usually an effort to

adopt a standard, repository-based process modeling tool. Henceforth all processes that are analyzed will be placed in a repository so that information can be accumulated and common processes identified and reused.

As they enter Level 3 and begin to focus on developing enterprise-wide models of their processes organizations begin to feel a need for enterprise modeling tools that can provide high level diagrams of all the processes in an organization and ways of tracking and decomposing the relationships between multiple layers of processes. Some get this from their more sophisticated process modeling tools and others buy stand-alone tools to provide enterprise modeling capabilities.

In a similar way, once companies move beyond simply sorting out their enterprise-wide process architecture they begin to focus on managing and monitoring processes and tools that can support process monitoring become popular. At this point, somewhere between level 3 and level 4 companies begin to seriously consider how they could use a BPMS suite or platform with its variety of tools and its ability to support the day to day management and monitoring of business processes.

Of course an IT group could buy a BPMS suite, no matter how mature their organization’s business people are in the management of their processes. In fact, this has happened with some frequency in the past decade. Ultimately, however, unless the IT group decides to simply use the BPMS tool as a software development environment, it means that the BPMS tool is used on one or two projects and then set aside. In other words, a level 2 organization simply doesn’t understand its processes well enough to appreciate what it can do with a BPMS platform. That changes, quickly, once the organization begins to grapple with process management and measurement issues and begins to consider how sets of processes can be managed together as a value stream.

When you consider that most companies are at Level 2 and just beginning to struggle to become Level 3 organizations, you realize that the current BPMS market is limited, and its growth will depend on the growing process maturity of organizations. This will not occur over night, but many of the new tools available – as for example the Supply Chain Council’s SCOR framework or the TeleManagement Forum’s eTOM framework – are capable of moving an organization from a Level 3.0 to a level 4.5 organization in a very short time by quickly providing a detailed framework for an enterprise architecture and process measurement and management system.

Still, we expect most organizations to struggle with internal process documentation, process analysis and redesign for several years before they reach the point at which they see the advantage of wide-spread adoption of the more sophisticated BPMS platforms that are now available. Transformation takes time.

17

Moore’s Technology Lifecycle and BPM

Geoffrey Moore is a high tech marketing guru who has been involved in numerous technology launches. He wrote a very popular book, Crossing the Chasm, (Harper Business, 1991) which describes the lifecycle of new technologies and the problems they face gaining widespread acceptance. The model is presented in Figure 7. The main phases of a technology lifecycle are described below.

Innovators. New technologies, according to Moore, are initially adopted by Innovators, companies that are focused on new technologies and are willing to work hard to make a new technology work in order to gain an early advantage. Innovators have their own teams of sophisticated technologists and are willing to work with academics and vendors to create highly tailored solutions.

Early Adopters. Once the Innovators prove that a new technology can be made to work, Early Adopters follow. Early Adopters are not focused on new technologies, as such, but on new business approaches that can give them a competitive advantage. They are less technologically sophisticated than Innovators, but still willing to work hard to make a new technology perform, if they see a clear business advantage.

Figure 1. Moore’s technology adoption life cycle curve

The Early Majority. The market for a new technology doesn’t really get hot until the Early Majority are convinced to adopt the technology. The Early Majority represent some 35% of the market. They won’t adopt new technology until they consider it well-proven. In fact, they aren’t interested in technology at all, and don’t have a lot of sophisticated technologists who are willing to struggle with the technology. They wait for case studies to show that the technology really provides the benefits that are claimed. And they insist on products that make it easy for less sophisticated developers to deploy the technology quickly, without significant difficulties.

Moore’s Chasm. Moore’s Chasm looms between Early Adopters and the Early Majority. Lots of technological innovations that are tried by Early Adopters fail to gain sufficient acceptance to pass the criteria of the Early Majority. The new technology gets lots of publicity, for awhile. Conferences are launched to provide information about the technology and it is described in glowing articles in all the high-tech magazines and business publications that are always touting the next new thing. Ultimately, however, the technology fails to produce enough concrete proof of usability and benefits to convince the Early Majority to make an investment, and the technology drops out of sight.

18

The Late Majority and the Laggards. The Late Majority, like the Laggards who lie even further to the right, are reluctant to spend money or take chances on new approaches. They wait till their competitors among the Early Majority have started gaining benefits from the technology, and then follow suit, reluctantly.

When you go to conferences and hear vendors talking about the technological features of their product and why its better technology than whatever came before, you are in an Innovator’s Market. When the market begins to transition to Early Adopters, you begin to hear more business cases and get information on specific benefits. This is also the time when vendors begin to worry about wider acceptance, and become concerned with standards, user interfaces, and assuring their products can work with legacy applications. If the technology is really successful and crosses the chasm, the technology conferences tend to drop away, and the vendors begin to show up at traditional business shows and promote their products as a cost-effective way to solve a class of business problems. The majority don’t care about technology. They just want to solve business problems quickly and effectively and to stay ahead or at least even with their competitors.

When a new technology is first introduced, lots of relatively small vendors rush to offer products. As long as the market is small, ironically, the number of vendors is large. No one vendor makes very much money, but they are full of hopes, each believing that their technological approach is superior. As the market grows and customers become a little more sophisticated, they begin to demand more comprehensive products and features like support for evolving standards. It is not uncommon for products to go through 3-4 generations in the course of 2-3 years. The cost of constantly developing new versions of one’s product, coupled with the need for more aggressive advertising, forces the smaller vendors to search for capital to continue to remain competitive.

Sometime during the Early Adopter phase of the market, the major vendors begin to incorporate the technology into their more comprehensive offerings, and begin to promote the technology. In effect, the large vendors guarantee that the new technology is safe. As the competition heats up, most of the small vendors disappear. Some are acquired by large vendors. Many decide to specialize in industry or niche specific markets. Others simply fail to earn enough money to survive. The key thing, however, is that Majority companies only buy from established vendors who they are reasonably confident can provide the rather extensive support they will require and who they are sure will still be in business 5 or 10 years from now. Thus, if a new technology succeeds in crossing Moore’s chasm, the leading vendors will be companies like IBM, Microsoft, and SAP. One or two of the new startups may have been successful enough to have grown into a 100 million dollar company and still be viable in the Majority market, but most won’t make it.

Moore’s Model and BPM Market

It is difficult to apply Moore’s model to the BPM market, as a whole, because today’s BPM market is really lots of separate markets.

A quick glance back at Figure 1, for example, suggests that process modeling vendors and their products have been around since the late Eighties. These are mature products and have been widely adopted. As it happens, Moore’s approach and the Maturity Model we just discussed work in sync for this product category. Most companies are ready for process modeling tools and the tools themselves have been around long enough to become mature and have passed over Moore’s chasm.

The same can not be said of Enterprise Modeling tools or BPMS platforms, however. These are relatively need tools and most companies are not mature enough to determine exactly how these tools would be useful. Thus this market, in spite of quite a bit of consolidation and a growing list of successful applications, is probably still only in the late stages of Early Adopter phase. The growing availability of BPMS platforms is countered by the fact that these tools keep changing their

19

configuration by adding new technologies. Adding rules and BI while simultaneously adding SOA increases the learning curve for organizations and has slowed widespread acceptance.

The growing availability of BPMS platforms from vendors like IBM, Oracle, Software AG and SAP will certainly accelerate adoption, but it will probably take a few more years before we can confidently say that the BPMS platform products have entered the Early Majority phase.