BPM Product Report Introduction and Overview (2010)

8/4/2019 BPM Product Report Introduction and Overview (2010)

1/21

A BPTrends Report

BPM ProductReport

Introduction andOverview

Paul Harmon

www.bptrends.com


2/21

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

Moores Technology Lifecycle and BPM ..... 17


3/21

1

Foreword

Beginning in 2005 BPTrends published our BPM Software Products Reports describing some of theBPM 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 changesresulting from the many mergers and acquisitions that have occurred and adding new vendors wehave identified.

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

Our objective is to present the various options within the BPM software market - not to choose orrank the best BPM products. Thus, unlike Gartner that has an extensive features list, we have aset 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 thedevelopment of BPM applications. We focus on positioning each product in terms of its uniquecapabilities and primary strengths.

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

Initially, we define the following 3 basic product categories:

x Enterprise, Modeling and Simulation Tools

x Business Rule Management Tools

x Comprehensive BPM Suites or Platforms

We recognize that the market is evolving and that different companies have different strategies. Forexample, some BPM software products focus on managing processes that are largely manual, whileothers 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 Webenvironments.

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 wereevaluated in the same manner: BPTrends prepared a detailed questionnaire that each vendor wasasked to complete. We reviewed the vendor questionnaires, and other relevant materials provided bythe 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 beincluded should contact Carolyn Potts, at [email protected].


4/21

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 andCarolyn Potts for her editorial and production contributions. And, I want to thank all the currentand future participating vendors for their cooperation. Finally, I want to thank all our BPTrendsmembers and readers who continue to support us. We hope this report is informative and useful toall of you.

Celia WolfFounder, CEO and PublisherBusiness Process [email protected]


5/21

3

The Business Process Management Decade

To understand where Business Process Management software is today, you need to understandwhere 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: BusinessProcess Management: The Third Wave, by Howard Smith and Peter Fingar, and the first meetings of theBusiness 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,

Harmon

BP Change

OASIS

BEPL

Standard

Internet/

Web/XML

Client

ServerComputing

Service

OrientedArchitecture

Personal

Computer

Consolidation

of BPMS

Market

ERP

Vendor

BPMS

Decision

Centric

BPMS

Emerging

BPMSPlatform

Business Rule Mang.

Software

Business Intelligence & Data Mining

Hammer &

Champy

Reengineering

Corp.

Six Sigma

MotorolaRummler-Brache

Improving

Performance

Ent. Application

Integ. Software

Workflow

Centric

BPMS

EAI

Centric

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 themainstream of business process work, and had usually been used to refer to efforts to better manageprocess change efforts within organizations. BPM, as used in the title of Roger Burltons 2001 bookof the same name, for example, described an approach to process management and a processimprovement 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 bookand BPMI both argued that the Web, and XML in particular, would make it possible to integratesoftware 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 managethe execution of business processes. Workflow tools had been used to create workflow applicationsthat functioned in this manner in the late Nineties. The best workflow applications allowedorganizations to scan documents into a repository, and then rely on a workflow application to senddigital copies of each specific document to the computers of the employees who needed toparticipate in the processing of the documents.

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


6/21

4

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

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

What Smith, Fingar and the founders of BPMI all realized was that by early 2000 it was possible tointegrate 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 anykind of business process that a company might want to automate.

There were a few BPMS tools built in the early years of the 2000s that tried to implement anintegrated 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 softwaretools. Similarly, several EAI vendors rushed out new versions of their products and also termed theirnew versions BPMS products.

In a similar way, several software vendors who were selling business rule management tools offerednew versions of their products and termed their offerings BPM software packages. This was thesituation 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 ownBPMS products which they positioned as a way to organize and manage their ERP applications asbusiness processes. Thus by the mid-2000-2010 decade SAP was building BPM capabilities intoNetWeaver, 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 anddocument 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 andintegrating software applications to support a process flow, but less capable of handling workflowand 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 2000s came from theComputer Aided Software Engineering (CASE) tradition that had flourished at the very end of theEighties and largely died in the early Nineties, when most companies began to shift from mainframesto client server-based systems. Most of the CASE vendors that survived either specialized in helpingsoftware developers model their applications, or they shifted, learned more about business processreengineering and offered software modeling environments for Six Sigma practitioners and Business Analysts. Both types of vendors repositioned themselves and called themselves Business ProcessModeling tool vendors. A good example of the former is IDS Scheers ARIS which specialized inhelping software developers design SAP applications. The latter, including vendors like ProForma,Casewise, and MEGA, developed very good user interfaces that business people could use. Businessusers who were familiar with the better Process Modeling environments found the early workflowand EAI derived BPMS tools which were all originally designed for software developers -- difficultto use.


7/21

5

This situation touched off the beginning of the BPMS consolidation that has been gainingmomentum since the middle of the 2000-2010decade. First, workflow and EAI vendors acquiredProcess Modeling tool vendors to gain better interfaces and more knowledge about how businesspeople 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 toextend 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 managementengine from someone else and simply include it into their BPMS offering, but as the first decade ofthe 2000s 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 ArtificialIntelligence (AI) and Expert Systems boom of the mid-Eighties. When the interest in ExpertSystems begin to fade at the beginning of the Nineties the expert system tool vendors began toreposition 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 headsof human experts. Business Rules, on the other hand, were usually derived from company policies orfrom 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 easierto maintain.

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

By 2007, the leading BPMS products represented a combination of workflow, EAI, and processmodeling, 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 BPMIgroup which subsequently merged with the Object Management Group (OMG) has becomeextremely popular and most BPMS vendors now offer support for this reasonably straightforwardway of diagramming processes. The BPMN standard has a core notation that business managers canuse and a much more detailed notation that software developers can use to generate a diagram thatcan, 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 describesprocesses in a formal syntax which can be converted into executable code. A popular idea has beento 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 versionof BPEL that will fully support both workflow and EAI concerns. (BPEL is better at generatingprocesses that manage EAI than processes that involve employees and documents.) Enthusiasm forBPEL seems to be declining.

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


8/21

6

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

In addition, toward the end of the decade some vendors began to use a variation on Data Miningtechniques to analyze process patterns using data that was stored in databases as the processes wereexecuted. Several BPMS products offer Process Mining capabilities. In essence, process mininglooks at existing databases that support existing business processes and then generates diagrams thatshow how data is flowing to and from the process-in-scope. Using this technique, a manager canbetter 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 00s, most large BPMS vendors began to promotethe idea of a Service Oriented Architecture (SOA) as a better way to manage infrastructuretechnologies. In BPM terms, this meant that the software modules that business activities calledupon were conceptualized as Services. As the leading BPMS vendors began to adopt SOA theybegan 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 howa company might develop and manage a business process whose BPMS engine resided on some


9/21

7

server that could only be accessed dynamically by means of the Web. Cloud Computing is onlybeginning to catch on, but it suggests that the BPMS platform has yet to assume its finalconfiguration, and that, in the meantime, companies will need to continue to struggle to determineexactly 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 thatBPMS has been a moving target. The competition has been fierce. When we did our first BPMSreport in 2005 we estimated there were 50-100 vendors offering products that could be broadlyconstrued as BPMS products. Today, in spite of considerable consolidation, there are still over 50vendors 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 businessmanager who is considering an acquisition to learn about the technological options available inBPMS 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 thatcould support any and all process initiatives that a large corporation might consider. The existingproducts may not quite match the vision, but the best of the BPMS platforms offer very

comprehensive support for process work. Its true that most of the BPMS platforms have yet to bewell integrated. Too many acquisitions have occurred too quickly, and todays large BPMS offeringsare often loosely bundled sets of products that were developed using more or less incompatibleunderlying technologies. It will probably be another five years before the existing BPMS platformsare tightly integrated behind intuitive interfaces, but that is clearly the direction in which the leadingBPMS platform vendors are heading.

The second tier of the market is still dominated by smaller, more specialized vendors. Many arestartups and are exploring new areas of process functionality. We fully expect that some of theBPMS vendors who arent acquired will specialize in particular industry niches, but that hasntoccurred yet. The major acquisitions have probably taken place but we fully expect to see newvendors 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 tobuild business process management systems that would let business managers control their ownprocesses. To date, most BPMS applications have been created by software developers or at least bybusiness analysts. Considering that the leading BPMS products are, in essence, based on decade-oldEAI and workflow platforms that were developed for programmers, this isnt very surprising. Theinitial BPMS products didnt have interfaces that would easily support their use by businessmanagers. Some of the tools have become better, but, at the same time, all the tool vendors werecontinually 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 existstoday is not something that most business managers find comprehensible. At their best, these BPMSplatforms will be used by Business Analysts and BPMS specialists. In most cases they will remainprocess-oriented software development environments.

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


10/21

8

dynamic processes processes that are being changed frequently, that rely on rapidly evolvingknowledge, 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. Theproducts of the major BPMS vendors will become more polished and they will be used by largecompanies. Those adoptions, and a growing number of interesting applications will convince othercompanies to explore the possibilities. Some will acquire the large generic BPMS tools offered bymajor platform vendors. Others, however, will be more interested in industry specific BPMSproducts or in the newer, manager friendly products available from the more innovative, smaller

vendors.


11/21

9

The Evolving Architecture of the BPMS Platform

Lets consider the evolving BPMS Platform in a little more detail. Before that, however, lets be surewe 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 andutilities that are used to create BPMS applications. A specific application is created by using theBPMS Platform to organize and control specific knowledge about a particular process. Most of theutilities in the platform must be embedded in each finished application, because it is the engines inthe platform that actually assemble and use the specific process knowledge at runtime. The specificknowledge may include process flow diagrams, business rules, and software applications used by theprocess, 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 theresulting performance data. In other words a BPMS Platform is used to create a BPMS Applicationand 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 BPMSapplications 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 aBPMS application.

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

In Figure 3 we represent the entire BPM Application as a single box. In Figure 4 we provide a moredetailed look at the architectural elements that might make up a specific BPMS platform. The BPMSPlatform combines a variety of tools and engines to provide a BPM group with all of thefunctionality 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 itconnected 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 theBPMS Platform. In the long run, large organizations will probably insist on a standard, independentprocess repository so that they can easily use multiple BPMS Platforms or shift between platformswithout losing their investment in BPM development.

Turning to the specific layers that make up the BPMS Platform, and working from the top layerdown we encounter BPM Tools, BPM Engines or Servers, Programming Interfaces/Tools andLanguage or Middleware. Well consider the elements of each, in turn.


12/21

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 tightlyintegrated 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 andSoftware Performance tools. We usually include technologies like BI and process mining in themonitoring/BI environments, and include tools that can be used to evaluate the performance ofspecific software applications being used by the process under Software Performance.

Process Modeling Environments provide users with a way of diagramming the flow ofthe application that is being created. The tools may include simple diagramming tools for businesspeople, 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 takespecific actions. One common approach is to divide the effort and specify the flow with a diagramand then specify how decisions are made by defining specific business rules to be applied to makeeach decision.

There are several Process Modeling Vendors selling stand-alone tools and some of the platformvendors sell their process modeling tools in stand-alone versions. This is important because mostbusiness process redesign work is done by business teams without any thought of automating theprocess. Instead, the process team is simply interested in defining how the process is done, andperhaps 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 theorganization. This type of capability is usually included in the more sophisticated Process ModelingTools, 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 intheir approach. Most of the activity in this area is with startup companies trying to create the firstreally popular enterprise modeling tool.

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


13/21

11

provided some way of capturing information about the execution of a process and relaying thatinformation to supervisors. Thus, most tools would monitor the flow of data through a documenthandling process and be able to report that agent 1 processed 50 documents in a day, while agent 2processed 43, etc. This information was useful to the manager immediately responsible for theprocess, but was too detailed for senior managers. As BPMS vendors sought to provide a morecomprehensive 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 leadingBPMS vendors forged relationships with Business Intelligence (BI) or Data Monitoring vendors andcombined data from process execution with other data in their organizational databases (e.g. data oncustomer satisfaction surveys, returns, complaints, etc.) which the BI tools summarized and analyzedfor patterns. Today, the best BPMS tools can provide senior managers not only with informationabout specific process events, but can track process trends, note problems and make suggestions fordealing with problems.

Some vendors have incorporated Process Mining capabilities into their tools. Process Mining is avariation on data mining that looks at the events that occur during processing (e.g. the data generatedby interactions between a process and a database) and provides a map of how the instances of aprocess flow. This kind of data may reveal interesting patterns. For example, the fact that instancesof 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, orActivity 4 and Activity 5 have different criteria or rules for processing the items in question. In eithercase, the Process Mining tool has highlighted a process problem for investigation. As time passes weare going to see BPMS products with more automated tools of this kind to help focus processmanagers on areas that need attention.

Business Rules Management Tools provide a way of documenting and automatingdecisions. At a minimum a Business Rules tool can be used to record business rules and keep trackof which activities use which rules. When the Business Rules Tool uses a rules engine, the tool canactually examine rules in response to process events and make decisions about how the processshould proceed. Using this approach, a customer can provide information about a desired car loanand the business rules system can check account balances, credit history, and so forth and then applya 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 arevery technical and designed for managing rules for detecting fraud or controlling a chemical plant tosimpler tools with spreadsheet-like interfaces that business managers can use to define whenpremium customers should be given discounts. Having independent rule tools is appropriate asmany companies still have completely independent business rules groups and process redesigngroups and do not think of the technologies as related. Increasingly, however, the two technologiesare being integrated and the leading BPMS vendors have bought business rules vendors to furtherthat integration in their BPMS platforms.

Software Performance Tools provide a way of determining the technical interactionsbetween a BPMS product and the software applications it manages. Thus, for example, a processmay 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 toexamine input and output data for each ERP application to identify where the slowdown hasoccurred. Although rather technical, these tools can provide powerful support when the process infocus 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 andused independent of process management work. Still, the integration of such tools into BPMSapplications provides a significant convenient tool for process managers working with EAI-orientedprocesses.


14/21

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 isimbedded 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 aremore 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. Lets consider the different types of engines your BPMSenvironment might have.

Workflow engines, as the term is used in BPMS, suggests an engine that interprets aprocess flow diagram and sends data from employee workstations to databases as defined by the flowdiagram. The workflow engine is the key to building a process management application that willorganize, control and monitor the work of employees during the execution of a process instance. The workflow engine moves data from workstations, obtaining employee approvals, allowingapplications to be check, handling rejections and sending out acceptance letters, etc. Vendors thatstarted 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 isespecially popular with vendors who seek to involve managers in the development and control ofprocesses applications.

Enterprise Application Integration (EAI) engines move data from one softwareapplication to another. In many cases BPMS products lean very heavily on operating systems andInternet 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 isexecuted. 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 softwareapplication. 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 mostpopular with the major OS/software platform vendors (IBM, Oracle, SAP) and they have been veryactive in acquiring smaller workflow vendors to round out their offering. In other words, most ofthe 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 andlinks business rules as the application is being executed. This is a bit simple as most have anintermediate stage where they compile a search tree, but the emphasis is on keeping the specific rulesindependent of the engine that examines the rules at runtime. This is done to assure that users canquickly change rules as needed. Most of these tools provide various utilities that allow the developerto specify the attributes and values that are used in rules and to organize rule sets. Since most rulesare used in more than one activity or process, one usually wants to store and manage rules indepdentof the process flow. In other words, when a given process requires rules to make a decision, theprocess flow engine ought to call the rule engine, which then examines the rule base and passes thedecision back to the process engine.

Initially most of the BPMS vendors were content to lease and embed rule engines in theirtools. Thus there were BPMS tools with rule engines and Business Rule Management Vendors whoprovided the actual rule environments that were embedded in the BPMS tools. At the same timethere were some rule vendors that didnt consider themselves BPMS players, but never-the-lessoffered Business Rule Management products which they sold directly to end users. Recently the


15/21

13

leading BPMS vendors have changed their approach and several of the Business Rule Managementvendors 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 todescribe 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 poorlyintegrated. In all cases, however, one interface is required to allow developers to enter informationinto the tool to create an application. At a minimum such an interface will allow the developer todefine a process flow, define rules and points where data will be gathered. It will allow the users tospecify employees who will be sent information at different points in the flow and it will specifywhen 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 essencethis interface allows managers to see what happens as specific instances of the application areprocessed. 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. Thissame interface may allow process managers to make specific changes in the runtime process tochange how subsequent instances are handled.

In many cases platform vendors with tools originally designed for software developers have acquiredprocess modeling or dashboard vendors to gain access to code that will allow them to offer betterinterfaces for business managers. In almost all cases the programming interfaces are a part of theBPMS 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 isbetween 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 tooperate on Java J2EE technology. Separately, there are considerations of how the BPMS producthandles access to other software modules. Most have an internal, OS or proprietary way of handlingapplication access, but a growing number are shifting to SOA approaches. Almost all of the BPMSproducts rely on the Internet and Web to access and distribute information and use XML to passdata. Some tools generate BPEL code to define workflow or interfaces, but as BPEL is not acomplete language, at this point, all supplement BPEL with other code making their applicationsmore or less proprietary, in spite of claims to the contrary. Do not plan to move a BPMS applicationbuilt in one tool to another tool without some reprogramming. This capability may come, but it willbe several years before it can be done without some reprogramming.

.


16/21

14

The Need for BPM Software in the Future

Still another way to think about the evolving BPM software market is to consider the currentmaturity 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) atCarnegie Mellon University in the Nineties, based on quality work originally undertaken by WattsHumphrey. Originally developed to support the analysis of software process maturity (CMM), thelatest version, the Capability Maturity Model Integrated (CMMI) has been generalized so that it canbe 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 determinewhere 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 aninformal description of the CMMI process maturity model.

Level 1. No Organized Processes. Level 1 organizations dont rely on processes. Thingsget done according to plans made on the fly. CMMI folks often refer to them as organizations basedon heroes. Things get done because someone makes a heroic effort and gets the report out at thelast 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 dont have a systematic procedure or the dataneeded to provide accurate answers to these questions.

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


17/21

15

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

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

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

Most organizations are not, of course, right at one level or another. Studies have suggested that mostorganizations in the US are somewhere between Level 2 and Level 3, trying to expand the processesthey 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 andmeasurement systems throughout the company.

In large organizations, it is common to find that one division or group will be at a different level ofmaturity 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 enterpriseand process redesign work and we have the strong impression that organizations at different levels ofmaturity use different software tools. Figure 2 places the maturity steps on the vertical axis and usescircles to suggest where most companies are today. This is a very impressionist diagram, but the datasuggests that most companies are at level 2 or just beginning to explore level 3.

Level 1.

No OrganizedProcesses

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 arent interested in process, or dont know what their processes are have no use forprocess tools. As they begin to move up the maturity scale and work to define their departmentalprocesses 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 toolsto help in the documentation and organization of their business rules.


18/21

16

A significant change takes place somewhere between Levels 2 and 3 as those in charge of processwork realize that they have been using graphic modeling tools (e.g. Visio) and that they have notaccumulated 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 processesidentified and reused.

As they enter Level 3 and begin to focus on developing enterprise-wide models of their processesorganizations begin to feel a need for enterprise modeling tools that can provide high level diagramsof all the processes in an organization and ways of tracking and decomposing the relationshipsbetween multiple layers of processes. Some get this from their more sophisticated process modelingtools 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 processarchitecture they begin to focus on managing and monitoring processes and tools that can supportprocess monitoring become popular. At this point, somewhere between level 3 and level 4companies begin to seriously consider how they could use a BPMS suite or platform with its varietyof 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 organizations businesspeople are in the management of their processes. In fact, this has happened with some frequency inthe past decade. Ultimately, however, unless the IT group decides to simply use the BPMS tool as asoftware development environment, it means that the BPMS tool is used on one or two projects andthen set aside. In other words, a level 2 organization simply doesnt understand its processes wellenough to appreciate what it can do with a BPMS platform. That changes, quickly, once theorganization begins to grapple with process management and measurement issues and begins toconsider 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 becomeLevel 3 organizations, you realize that the current BPMS market is limited, and its growth willdepend on the growing process maturity of organizations. This will not occur over night, but manyof the new tools available as for example the Supply Chain Councils SCOR framework or the

TeleManagement Forums eTOM framework are capable of moving an organization from a Level3.0 to a level 4.5 organization in a very short time by quickly providing a detailed framework for anenterprise architecture and process measurement and management system.

Still, we expect most organizations to struggle with internal process documentation, process analysisand 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. Transformationtakes time.


19/21

17

Moores Technology Lifecycle and BPM

Geoffrey Moore is a high tech marketing guru who has been involved in numerous technologylaunches. 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. Themodel 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 newtechnology work in order to gain an early advantage. Innovators have their own teams ofsophisticated technologists and are willing to work with academics and vendors to create highlytailored 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 newbusiness approaches that can give them a competitive advantage. They are less technologicallysophisticated than Innovators, but still willing to work hard to make a new technology perform, ifthey see a clear business advantage.

Figure 1. Moores technology adoption life cycle curve

The Early Majority. The market for a new technology doesnt really get hot until the EarlyMajority are convinced to adopt the technology. The Early Majority represent some 35% of themarket. They wont adopt new technology until they consider it well-proven. In fact, they arentinterested in technology at all, and dont have a lot of sophisticated technologists who are willing tostruggle with the technology. They wait for case studies to show that the technology really providesthe benefits that are claimed. And they insist on products that make it easy for less sophisticateddevelopers to deploy the technology quickly, without significant difficulties.

Moores Chasm. Moores Chasm looms between Early Adopters and the Early Majority.Lots of technological innovations that are tried by Early Adopters fail to gain sufficient acceptance topass 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 glowingarticles in all the high-tech magazines and business publications that are always touting the next newthing. Ultimately, however, the technology fails to produce enough concrete proof of usability andbenefits to convince the Early Majority to make an investment, and the technology drops out ofsight.


20/21

18

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

When you go to conferences and hear vendors talking about the technological features of theirproduct and why its better technology than whatever came before, you are in an Innovators Market.When the market begins to transition to Early Adopters, you begin to hear more business cases andget information on specific benefits. This is also the time when vendors begin to worry about wideracceptance, 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, thetechnology conferences tend to drop away, and the vendors begin to show up at traditional businessshows and promote their products as a cost-effective way to solve a class of business problems. Themajority dont care about technology. They just want to solve business problems quickly andeffectively 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. Aslong 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 morecomprehensive products and features like support for evolving standards. It is not uncommon forproducts to go through 3-4 generations in the course of 2-3 years. The cost of constantly developingnew versions of ones product, coupled with the need for more aggressive advertising, forces thesmaller 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 thetechnology into their more comprehensive offerings, and begin to promote the technology. Ineffect, 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 specializein industry or niche specific markets. Others simply fail to earn enough money to survive. The keything, 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 crossingMoores chasm, the leading vendors will be companies like IBM, Microsoft, and SAP. One or two ofthe new startups may have been successful enough to have grown into a 100 million dollar companyand still be viable in the Majority market, but most wont make it.

Moores Model and BPM Market

It is difficult to apply Moores model to the BPM market, as a whole, because todays BPM market isreally lots of separate markets.

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

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


21/21

19

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

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

BPM Product Report Introduction and Overview (2010)

Documents

Transcript of BPM Product Report Introduction and Overview (2010)