Cutter · The value of high-quality data ... BPM proof-of-concept or a full-fledged BPM rollout is likely to stumble across certain issues that may jeop-ardize the BPM effort —

The Journal of Information Technology Management

Cutter IT Journal

Vol. 20, No. 11November 2007

BPM: A Broken Promise or theBuilding Blocks of ModernEnterprise Architecture?

Opening Statementby Bartosz Kiepuszewski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Enterprise Architecture: BPM, SOA, and MDSDby Michael Hartges, Dirk Krafzig, Michael Kunz, Florian Mösch, Dirk Slama, and Thomas Stahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Adaptive Process Management Architecture: Enabling Enterprise Innovation by Marrying SOA to Business Rulesby Borys Stokalski and Marcin Strozanski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Are BPM Suites Ready for Prime Time? Lessons from a Proof-of-Conceptby Olivier Brousseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

BPM: Defining the Basics for Successby Mark Fung-A-Fat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

All That Glitters Is Not Gold: Selecting the Right Tool for Your BPM Needsby Nick Russell, Wil M.P. van der Aalst, and Arthur H.M. ter Hofstede . . . . . . . . . . . . . . . . 31

BPM Is the Way to Go

BPM sets the stage for process agility. Forfrequently changing, high-volume processoptimization, BPM is the right technologyand a promising approach that will flexyour IT architecture.

BPM Has a Ways to Go

BPM is an unfulfilled promise. Despitethe enormous hype and expectations, BPM is still more of a vision than a current,sound reality.

“Whereas some of the morehistorical BPM initiativeswere focused on automation,monitoring, and optimizationof business processes, themodern BPM approachstresses flexibility; that is,the ability to quickly changeprocesses as the businesschanges.”

— Bartosz Kiepuszewski,Guest Editor

http://www.cutter.com



Cutter IT Journal®

Cutter Business Technology Council:Rob Austin, Ron Blitstein, ChristineDavis, Tom DeMarco, Lynne Ellyn,Jim Highsmith, Tim Lister, LouMazzucchelli, Ken Orr, Ed Yourdon

Editorial Board: Larry L. Constantine, Bill Curtis, Tom DeMarco, Peter Hruschka, TomooMatsubara, Navyug Mohnot, RogerPressman, Howard Rubin, Rob Thomsett,George Westerman

Editor Emeritus: Ed YourdonPublisher: Karen Fine CoburnGroup Publisher: Chris GeneraliManaging Editor: Karen PasleyProduction Editor: Linda M. DiasClient Services: [email protected]

Cutter IT Journal® (ISSN 1522-7383)is published 12 times a year by CutterInformation LLC, 37 Broadway, Suite 1,Arlington, MA 02474-5552, USA(Tel: +1 781 648 8700 or, within NorthAmerica, +1 800 964 5118; Fax: +1 781648 1950 or, within North America,+1 800 888 1816; E-mail: [email protected]; Web site: www.cutter.com).

Cutter IT Journal® covers the softwarescene, with particular emphasis on thoseevents that will impact the careers of ITprofessionals around the world.

©2007 by Cutter Information LLC. All rights reserved. Cutter IT Journal®is a trademark of Cutter Information LLC.No material in this publication may bereproduced, eaten, or distributed withoutwritten permission from the publisher.Unauthorized reproduction in any form,including photocopying, faxing, imagescanning, and downloading electroniccopies, is against the law. Reprints makean excellent training tool. For informationabout reprints and/or back issues of CutterConsortium publications, call +1 781 6488700 or e-mail [email protected].

Subscription rates are US $485 a yearin North America, US $585 elsewhere,payable to Cutter Information LLC.Reprints, bulk purchases, past issues,and multiple subscription and site licenserates are available on request.

Part of Cutter Consortium’s mission is to fosterthe debate of, and dialogue on, the businesstechnology issues challenging enterprisestoday, to help organizations leverage IT forcompetitive advantage and business success.Cutter’s philosophy is that most of the issuesthat managers face are complex enough tomerit examination that goes beyond simplepronouncements. Founded in 1987 asAmerican Programmer by Cutter FellowEd Yourdon, Cutter IT Journal is oneof Cutter’s key venues for debate.

The monthly Cutter IT Journal and its weeklycompanion Cutter IT E-Mail Advisor offer avariety of perspectives on the issues you’redealing with today. Armed with opinion,data, and advice, you’ll be able to make thebest decisions, employ the best practices,and choose the right strategies for yourorganization.

Unlike academic journals, Cutter IT Journaldoesn’t water down or delay its coverage oftimely issues with lengthy peer reviews. Eachmonth, our expert Guest Editor delivers arti-cles by internationally known IT practitionersthat include case studies, research findings,and experience-based opinion on the IT topicsenterprises face today — not issues you weredealing with six months ago, or those thatare so esoteric you might not ever need tolearn from others’ experiences. No otherjournal brings together so many cutting-edgethinkers or lets them speak so bluntly onissues such as:

Proving the value of IT ROI

The give and take of offshore outsourcing

The value of high-quality data

The evolution of agile project management

When and how to kill a dying project

Cutter IT Journal subscribers consider theJournal a “consultancy in print” and likeneach month’s five or six articles exploring asingle topic to the debates they participate inat the end of a day at a conference — withevery participant in the conversation forcefullyexpressing his or her viewpoint, backing itup with data and real-life experience.

Every facet of IT — application integration,security, portfolio management, and testing,to name a few — plays a role in the successor failure of your organization’s IT efforts.Only Cutter IT Journal and the Cutter IT E-MailAdvisor deliver a comprehensive treatmentof these critical issues and help you makeinformed decisions about the strategies thatcan improve IT’s performance.

Cutter IT Journal is unique in that it is writtenby IT professionals — people like you whoface the same challenges and are under thesame pressures to get the job done. TheJournal brings you frank, honest accountsof what works, what doesn’t, and why.

Competition remains intense in the high-techworld. Budget cutbacks and short deadlineshave become the norm. You need advice andexperience you can rely on. Put your IT con-cerns in a business context. Discover thebest ways to pitch new ideas to executivemanagement. Ensure the success of your ITorganization in an economy that encouragesoutsourcing and intense international compe-tition. Avoid the common pitfalls and worksmarter while under tighter constraints. You’lllearn how to do all this and more when yousubscribe to Cutter IT Journal.

About Cutter IT Journal

Cutter IT Journal

mailto:[email protected]





Opening Statement

3Vol. 20, No. 11 CUTTER IT JOURNAL

Business process management (BPM) is a concept thathas been alive in the IT world for many years under theguise of various names and labels. In the client-serverera of the 1990s, BPM tools were called workflow man-agement systems. The main vendors from this era —FileNet, Staffware, IBM — and many others providedus with so-called workflow engines that, based on aprocess definition, would route work between processparticipants, be they human actors or computers. Backthen, the Workflow Management Coalition was formedwith the aim of standardizing the logical architectureand interfaces of typical workflow systems. The archi-tecture (The Workflow Reference Model Diagram1) hasnot changed one bit to this day. In fact, in most currentBPM toolsets we can still identify:

A process definition tool

An enactment engine (process server)

Administration and monitoring tools (these daysoften labeled business activity monitoring, or BAM,tools)

A workflow client application that handles workitems and invoked applications (nowadays, typicallyWeb services)

Workflow management tools (or process managementtools, as they started to be called) quickly became astandard offering of the more complex enterprise appli-cation integration (EAI) suites. As automatic manage-ment of business processes — especially ones that didnot require human intervention — was seen as one ofthe cornerstones of advanced EAI solutions, we sawleading EAI vendors putting BPM engines on top oftheir EAI suites. One of the popular ways many EAIvendors sought to fill the void in their EAI suites wasactually to acquire one of the former workflow vendors.

Today we are deeply entrenched in advanced enterprisearchitecture concepts that revolve around the idea ofservice-oriented architecture (SOA). Not surprisingly,BPM again is seen as an important — or perhaps a

fundamental — building block of SOA architecture.Since SOA (much more than those former EAI attempts)focuses on standards, we have witnessed a “BPMstandards war” with Business Process ExecutionLanguage (BPEL) emerging as a clear winner.

Since I started working on BPM-related issues back inthe mid-1990s, one thing has not changed — the mar-keting hype. Business users are led to believe that theycan effortlessly, without IT intervention, change busi-ness processes as they go and that they will be able toquickly assemble new business processes from prede-fined “building blocks” as their business changes. Butthe ability to change the business process “on the fly”is not the only perceived benefit of BPM. We also hearBPM suite vendors promising:

Fast development and improved time to market,with BPM suites having the ability to generate, froma model, complex, cross-departmental applicationsthat automate complicated process flows

Increased process transparency, traceability, andcontrol, which leads to better alignment of operationsand strategy and decreased risk of noncompliancewith standards and regulations

Process optimization and increased process effi-ciency, leading to reduced operation costs

A better foundation for continuous improvement of business processes

Better alignment between business and IT

Whereas some of the more historical BPM initiatives(such as workflow management systems) were focusedon automation, monitoring, and optimization of busi-ness processes, the modern BPM approach stresses flex-ibility; that is, the ability to quickly change processes asthe business changes. Over the years we have gottenbetter and better at process optimization, both fromthe business point of view (with approaches such asSix Sigma) and from the IT point of view (with ever-improving EAI technology and techniques, which allow

by Bartosz Kiepuszewski

Get The Cutter Edge free: www.cutter.com

1See www.wfmc.org/standards/referencemodel.htm.


©2007 Cutter Information LLCCUTTER IT JOURNAL November 20074

for more straight-through processing and faster busi-ness cycles). Today, however, the main business focusis on agility and innovation, thanks to a fast-changingbusiness environment as well as new products, businessmodels, and government regulations disrupting day-to-day business operations. In this environment, IT mayfind that — instead of its traditional role as an enabler— it may suddenly become a roadblock to fast businesschange. Interestingly enough, it is quite possible thatyour BPM efforts from several years ago may todayform a hard-to-get-rid-of IT legacy.

In this issue of Cutter IT Journal, our authors offer theirviews of modern BPM and present us with a few casestudies that show us what, in their opinion, can beachieved and what should be avoided. With such along list of promised benefits, it is perhaps not surpris-ing that many vendors are trying to ride the BPM waveand many business users and IT departments are tryingto realize some of these benefits. However, when pushcomes to shove, a typical organization attempting a

BPM proof-of-concept or a full-fledged BPM rolloutis likely to stumble across certain issues that may jeop-ardize the BPM effort — especially when the mainexpected benefit is flexibility and agility. So let us havea look at how our authors define BPM and approachBPM initiatives.

In our first article, Michael Hartges, Dirk Krafzig,Michael Kunz, Florian Mösch, Dirk Slama, and ThomasStahl see BPM as a management discipline comprisinganalysis, planning, control, and optimization of busi-ness processes. They distinguish BPM from otherapproaches such as business rules management (BRM),workflow management, process-driven business intelli-gence (BI), and others, emphasizing that BPM particu-larly promises optimization potential for businessprocesses if workflows can be defined explicitly, thepotential for process optimization is high (as shouldbe the case for frequent, repeatable processes), and thecourse of the process changes frequently. They presentus with a comprehensive vision for BPM and “enter-prise SOA” that includes both BPM and BRM. In theview of Hartges et al., BPM is part of a broader, SOA-based enterprise architecture, consisting of enterpriseportals, a portfolio of enterprise services, operationaldata stores, and a data warehouse. The authors con-clude with a case study of T-Mobile’s BPM/SOA efforts,which provides us with a specific approach to BPMimplementation.

In our next article, Cutter Senior Consultant BorysStokalski and Marcin Strozanski offer a case studyfrom Telekomunikacja Polska S.A., a large Polishtelecommunications group, which is aiming to makeits organization more agile by pursuing what Stokalskiand Strozanski label “adaptive process automation.”The authors see BPM tools as specialized middlewareand management tools that can help an organizationto quickly assemble services implemented in its enter-prise services portfolio into an automated process andto orchestrate its execution. Such tools pave the way tothe prototyping of business processes in a way similarto application prototyping. However, to achieve theholy grail of the adaptive enterprise (i.e., adaptiveprocess automation), one needs much more than that — specifically, business rules engines, e-learning andcontent management tools, and BI components, allwith the foundation of service-oriented architecture.It is the introduction of BRM into the enterprise archi-tecture of their client that makes their experience ofparticular interest.

IN NEXT MONTH’S ISSUEEnterprise 2.0: Will Corporations Embracethe Social Media Revolution? Guest Editor: Vince Kellen

Following quickly on the heels of Web 2.0 comes Enterprise2.0. Loosely described as a set of collaborative technologiesthat work both inside the company’s boundaries and acrosspartners and customers outside the company, Enterprise 2.0is gaining in popularity. Industry conferences and trademagazines have been prattling on about how these tech-nologies will transform businesses. But is Enterprise 2.0just hype, or is it here to stay? In next month’s issue ofCutter IT Journal, we’ll discuss the world of social comput-ing beyond YouTube and MySpace. You’ll learn what sepa-rates Enterprise 2.0 from Web 2.0 — and the advantageseach one can offer the enterprise sector. You’ll hear fromone author who believes that not only have the fundamen-tal rules of business not changed, they are also the bestway to understand how Enterprise 2.0 practices and tech-nologies can benefit your firm. And you’ll discover howto walk the line between “peer production” and “privatevalue” to reap competitive advantage from Enterprise 2.0.Tune in next month and join a (potential) revolution alreadyin progress.

5Get The Cutter Edge free: www.cutter.com Vol. 20, No. 11 CUTTER IT JOURNAL

Next, Olivier Brousseau of Schlumberger tells us howthe oilfield services company challenged the five lead-ing BPM suite suppliers to engage in a BPM proof-of-concept. The part of Brousseau’s case study I found themost interesting was when Schlumberger gave the ven-dors the task of performing one or two process changes,consisting of adding an information item in one of theforms and adding an approval step to be performed byan additional role in the process. This seemingly simplechallenge produced some interesting results that willhelp us assess the current maturity of BPM solutions.Despite his focus on tools, Brousseau views BPM as adiscipline that covers both management and technicalaspects of process orientation. The most important shifthere is a focus on end-to-end processes that span multi-ple business units. Management of such processes typi-cally requires C-level executive support, as no singlebusiness unit would take responsibility for the wholeprocess.

For Mark Fung-A-Fat, our next author, BPM is primar-ily a management discipline. In fact, he sees any organi-zational effort aimed at documenting, improving, andbetter managing business processes as part of BPM.Fung-A-Fat warns us against approaching BPM withthe idea that introducing a “magical” packaged solutioninto an organization will automate all its processes,making them inherently more efficient. He cites threecase studies from the Massachusetts Medical Society(MMS) in which successful streamlining of processflows has been achieved using various tools and tech-nologies that we do not typically associate with BPMactivities. Interestingly, for Fung-A-Fat, it is BPM thatdrives SOA implementation, not the other way around.

Last but not least, Nick Russell, Wil M.P. van der Aalst,and Arthur H.M. ter Hofstede provide us with a very different view on BPM tools and technologies,approaching them from a more academic perspective.Their patterns-based framework gives a potential BPMbuyer a tool for assessing the suitability of a potentialBPM suite. The apparent complexity associated withreconciling the needs of the organization and the capa-bilities of available products stems from the fact thatthere is no common theoretical foundation for BPMtechnology, and BPM tool vendors come from diversebackgrounds, such as office automation, traditionalworkflow systems, tracking systems, and even projectmanagement, with its PERT and Gantt charts. What I

find to be one of the most sobering conclusions fromtheir research is that standards such as Business ProcessModeling Notation (BPMN) and BPEL, instead of order-ing, structuring, and cleaning out the BPM suite market,seem to add another layer of confusion and complexity.

From a theoretical point of view, automation of businessprocesses is, to put it simply, tough. To name a fewproblems, we still don’t seem to agree on a theoreticalfoundation for BPM, there are very complex issues asso-ciated with transaction management of long-runningprocesses, and modeling languages lack the formalsemantics necessary for easy interoperability. If indeedmodern BPM is all about making an organization moreagile, then on top of these problems, we add anotherlayer of complexity associated with change. As businessprocesses change, one may need to change underlyingservices, implying change to applications and systemsthat expose these services. It is naive to assume thatBPM tools by themselves allow for easy process changein an organization. However, moving process logic outof silo application suites, exposing process definition tobusiness users, and augmenting BPM suites with BRM,modern BI, and knowledge management might eventu-ally get us to our vision of IT being able to fully supportthe adaptive, ever-changing enterprise. We might not bethere yet, but we are certainly moving in the right direc-tion. If you want to see in more detail where are wenow, what to look for, and where not to get too carriedaway by marketing hype, read on!

Bartosz Kiepuszewski is a Senior Consultant with CutterConsortium’s Agile Product & Project Management and EnterpriseArchitecture practices. He also serves as a board advisor for BusinessManagement Software, a Poland-based software development com-pany. Dr. Kiepuszewski, who specializes in J2EE architectures, work-flow systems, and agile software development, holds a PhD fromQueensland University of Technology, where he worked on theoreticalfoundations for workflow modeling languages. Before joining BusinessManagement Software in 2007, he worked for five years in Australia,first at the Distributed Systems Technology Centre as a researchscientist, and later at Mincom Ltd. as a senior J2EE architect.Upon returning to Poland in 2001, he joined Infovide, a polish ITconsulting company where he helped to develop and run agile soft-ware development and enterprise architecture consulting products.Dr. Kiepuszewski has authored numerous research papers, primarilyin the workflow area, and he is a frequent speaker at national andinternational conferences, seminars, and trade shows. He can bereached at [email protected].


Defining a strategy and a conceptual approach forbusiness process management and introducingit in enterprises is a challenging task. Successful BPMinitiatives — nowadays predominantly conducted inthe course of service-oriented architecture (SOA) initia-tives — must find solutions and consensus and effectchanges in a number of areas partly situated in busi-ness, partly situated in IT. This involves:

Creating a vision, setting realistic expectations andgoals for BPM, and separating hype from reality

Defining a reasonable “model chain” from businessartifacts to runtime artifacts and back to businessartifacts

Defining a reasonable tool chain from businessartifacts to runtime artifacts and back to businessartifacts

Instituting a process for introducing BPM and itsrelevant stakeholders

After providing a conceptual overview of these areas,including their interrelations to SOA and model-drivensoftware development (MDSD), we discuss best prac-tices and factors organizations should consider whenimplementing BPM, based on a large number of real-world projects in complex client scenarios. In the lastpart of the article, we describe the BPM effort T-Mobileis currently conducting in the course of its internationalSOA initiative.

OVERVIEW

SOA and BPM represent two of the most importanttrends in IT for large enterprises. Whilst SOA is oftenregarded as an IT discipline, BPM — which compre-hends analysis, planning, control, and optimization ofbusiness processes — inherently implies joint activitiesbetween IT and business units and the managementof both of them. From a business point of view, BPMpromises greater flexibility of IT-supported businessprocesses, better traceability and control, a betterfoundation for continuous improvement of businessprocesses, and, potentially, cost reductions due toincreased automation. For IT departments, BPM canincrease the transparency of IT processes, which helpsto streamline underlying application landscapes andimproves the cooperation between business and IT.

Beyond this common core of most BPM initiatives, thescope varies widely, ranging from local optimizationof individual processes to global improvements andindustrialization (see Figure 1).

BPM is applicable and the effort is justified if:

The workflow can be described explicitly

The potential for optimization is sufficiently high(e.g., due to the number of executions of the work-flow or if there are requirements concerning trace-ability of the process, because of legal restrictions)

The course of the process changes with a certainfrequency

In a larger enterprise, the evolution from implicitprocesses (more or less hard-coded in presentationlogic, midtier and back-end applications, or databaselogic) to explicit flexible digital processes typically lastsa decade and consists of more than one evolutionarystep. Business intelligence (BI) tools allow businessunits to subsequently assess the performance of implicitprocesses through the analysis of business-relevant datalogged by these processes. Business activity monitoring(BAM) tools enable them to perform these analyses inreal time. The last stage of expansion represents theadoption of BPM systems (BPMSs).


Enterprise Architecture: BPM, SOA, and MDSDby Michael Hartges, Dirk Krafzig, Michael Kunz, Florian Mösch, Dirk Slama, and Thomas Stahl

MODEL CITIZENS

BAM

BPM

BRM

Portal

HighFrequencyof Change

LowFrequencyof Change

ImplicitProcesses

ExplicitProcesses

Collaboration

Suites,

E-Mail

Process-

Driven BII

WFM

Highly Dynamicor High Potentialfor Optimization

StableProcesses

Figure 1 — BPM and related approaches.


THE BPM VISION: DIGITAL PROCESSES

According to the promises of BPM, processes are mod-eled, deployed, executed, monitored, and analyzedjointly by business and IT in a cycle of continuousimprovements. In the first step, a process is explicitlymodeled. Afterwards, it is deployed and executed intoone or more runtime environment(s), monitored duringexecution, and analyzed according to a set of business-relevant characteristics (e.g., cycle time, process costs).For observed deviations from designated characteristics,solutions are developed and an improved version of theprocess is modeled (see Figure 2).

ENTERPRISE SOA = SOA + BPM + BRM

In contrast to SOA, the term “enterprise SOA”describes the complex interaction of various elements,including BPM and business rules management (BRM)(see Figure 3).

Portals ( ) are situated at the top layer of an enterpriseSOA architecture and are the entry point for executing,

monitoring, and analyzing processes. These processescan be implicit (BI or standalone BAM) or explicit (BPMwith BAM).

The process layer ( ) comprises modeling and executionof business processes, often including modeling and exe-cution of business rules based on a BRM system (BRMS).

In executing process steps, the business process usesapplication logic exposed as services. Basic services ( )provide existing application logic ( ) and standardizedaccess to operational data ( ) supplied by an EnterpriseService Bus (ESB, ). Data warehouses nowadays oftenprovide operational data as SOA services ( ).

As a best practice, basic services are aggregated bymeans of orchestration to more business-related com-posite services ( ), linked as another best practice toartifacts of the business architecture (e.g., a businessfunction within a business system). A composite servicetypically runs within milliseconds and consists solelyof machine-machine interaction, whereas a businessprocess is potentially long-running and interruptible,

ContinuousImprovement

Execute process

ExecuteProcess

(Re-) modelprocess

(Re-)ModelProcess

(Re-) deployprocess

(Re-)DeployProcess

Understandproblem

UnderstandProblem

Developsolution

DevelopSolution

Start

BAMMonitor

process instances

MonitorProcess InstancesBPM

Analyseprocess logs

AnalyzeProcess Logs

Figure 2 — Cycle of BPM and BAM for continuous process improvement.

Operational Systems Business Intelligence

Operational Applications Legacy CRMERP

Basic Services

BPM/BRM

ProcessPortal

DWH Mart

CompositeServices

ESB

Operational Data Stores

BAM/Process Process

KPIs

ETL

AnalyticServices

Data Warehousing

Monitoring Analysis1

2

3

4

5

6

7

8

9

10

Figure 3 — Enterprise SOA blueprint.



can include human interaction, and has a definablebusiness impact.

Analytic SOA services ( ), which are building blocks foranalytic applications, support the semantic integrationof historically grown complex BI environments into anenterprise SOA, including access to operational data ( ).

The integration of BI into enterprise SOA furthermoreassists in controlling, analyzing, and improving processesbased on key performance indicators (KPIs, ).

INTERRELATION OF BPM-RELATED ENTERPRISESOA ARTIFACTS

Figure 4 gives a survey of BPM-related enterprise SOAartifacts, usual implementation technologies, responsibil-ities, roles involved, and typical frequencies of change.

MDSD WITHIN BPM AND ENTERPRISE SOA

Model-driven software development is a developmentapproach that utilizes models not as simple documenta-tion but as a formal specification that provides the basisfor generating artifacts automatically (e.g., executablesoftware). The goal of MDSD is a (partial) automationof the software development process in a specifieddomain. Such domains can be scoped vertically bybranches (banking, telecommunications, healthcare, etc.)or horizontally by architecture (n-tier Web application,rich client, SOA/BPM, etc.). In each case, the core con-cepts of the domain are to be formalized and deliveredto the application development process in terms of adomain-specific modeling language (DSL). In practice,this may be a UML profile, a specific graphical languagewith editor, or an XML schema definition. Models for-mulated in such a DSL can be translated by automatedtransformations either directly into the source code of aprogramming language (model-to-code transformation)or into models of a lower level of abstraction (model-to-model transformation).

The use of several layers of abstraction (called cascad-ing) is typical for MDSD, the top layer being ratherbusiness-centric and the bottom layer being platform-or technology-centric. An architecture-centric abstrac-tion layer typically lies in between. In such a case, threelayers are mapped to each other through the use oftransformations. Model Driven Architecture (MDA) isa standardization initiative of the Object ManagementGroup (OMG) within the topic of MDSD. The MDAstandard explicitly defines three layers with differ-ent levels of abstraction; namely, the computation-independent model (CIM), the platform-independentmodel (PIM), and the platform-specific model (PSM).

The advantages of the MDSD approach are manifold.The reduction of technology ties and decreased vendorlock-in are especially notable. Further essential advan-tages of MDSD are:

Decoupling, regardless of the huge variety of technol-ogy stacks or products

Significant acceleration of the development process

Improved quality of the developed software or soft-ware configuration

One very important and practically relevant questionconcerning MDSD deals with the reversibility of thetransformation chains. As an example, traditional UMLtools surely allow the translation of given artifactsbased on source code into a UML model via reverseengineering. Taking a closer look, one will notice thatthis process is merely a code visualization; the programcode constructs are just represented graphically, so thatthe main benefits of abstraction — simplicity, maintain-ability, and efficiency — are not achieved. Models witha higher level of abstraction cannot (for mathematicalreasons) be regained from a given code base. Therefore,MDSD pursues a clear forward-engineering approachand consciously abstains from roundtrip technologies.

Within the (horizontal) domain of BPM and enterpriseSOA, a model-driven approach can be used at a certain

Enterprise SOA Artifact

ImplementationTechnology

Responsibility Role Frequency of Change

Business rule

Basic service

Composite service

Coded application logic(e.g., Java, COBOL)

Process

Technical rule

Coded application logic orBPMS (orchestration)

BPMS

BRMS

BRMS

IT department

IT department

IT department

IT department

Business unit

Technical developer

Technical developer

Business analyst

Business analyst

Business unit

Quarter

Quarter/ month

Month

Week

Day

Figure 4 — Survey of BPM-related enterprise SOA artifacts.


point to define business models (e.g., process models)that are formally specified and can be transformed auto-matically into deployable and executable artifacts.

Within a tool-centric approach without MDSD, the sep-aration of concerns on the business and technologicallevels is typically much less pronounced, leading to:

A higher degree of dependency of business contenton technology and tool vendors

Higher complexity for the business and IT users ofthe BPM approach

Conversely, this does reduce the short-term complexityfor the BPM initiative’s engineering team.

By means of MDSD, business-oriented descriptions ofthe processes and runtime-oriented descriptions can bedecoupled, thus optimizing both types of models fortheir respective intended uses. On the one hand, busi-ness models (representing a higher level of abstraction)can be optimized concerning clarity, independence fromruntime environments, and the like. On the other hand,deployment and runtime-oriented models (derivedfrom these business models) can be aligned to a set ofpotentially heterogeneous runtime environments andnot interfere with requirements at the level of businessmodels. Furthermore, the separation of business contentfrom less stable technological decisions on the level oftools and suppliers allows separate lifecycles for thesetwo areas.

From the point of view of abstraction, applying theMDSD principles on the domain BPM/SOA could bevisualized as shown in Figure 5.

Business process modeling operates on an abstrac-tion level of a CIM, comprising IT-supported and IT-unsupported processes and activities and describingthem in formal, semiformal, or informal “models” (e.g.,an event-driven process chain) using tools such as ARISor ADONIS.

Examples of architecture-centric, platform-neutral nota-tions for BPM and SOA models on the level of a PIM areBusiness Process Modeling Notation (BPMN), XMLProcess Definition Language (XPDL) or UnifiedModeling Language (UML).

Business Process Execution Language (BPEL) and WebServices Description Language (WSDL) are examples ofexecutable, platform-specific artifacts.

Artifacts on a lower level of abstraction can be auto-matically generated from artifacts on a higher level ofabstraction by means of model-to-model-transformationsor model-to-code-transformations, provided theirdescription is formal. Runtime attributes of artifacts

on a lower level of abstraction can be mapped to theircounterparts on a higher level (e.g., in the course ofBAM). Processes and services on the PSM level have adefinition and a deployment/runtime view, consistentlyderived from shared models on the PIM level.

BPM and SOA based on MDSD therefore can lead to:

Abstraction of business-level artifacts, which aretransformed at implementation time in a consistent,automated way into technology-level artifacts,which are dependent on all variants of potentiallyheterogeneous runtimes (e.g., BPM engine, ESB).

Backward traceability from lower levels to higherlevels, allowing, for example, correlation of runtimeevents to business artifacts, including the possibilityof utilizing concepts like a management cockpit.

THE ROLE OF METADATA

All artifacts of an enterprise SOA and their relations,including the BPM- and MDSD-related parts, should bestored in one logical metadata repository, both specifi-cally designed for enterprise SOA artifacts and flexibleconcerning the metamodel. In addition to these designtime–relevant artifacts, a metadata solution should alsocontain runtime-relevant aspects in a coordinated way(registry/repository solution). All real-world products inthis area today primarily have a “technical” background,so they should be supplemented with a suitable tool forarchitectural management and planning that is specifi-cally designed to support all aspects of introducing,

PSM

PIM

CIM

Vorgangsendedaten

AllgAntragsdatenBearbeiten

SpartenAnzeigenPolicendatenBearbei ten

All gSpa rtend ate nBearbeiten

defaul t

Start

[ Weiter ] [ Zurueck ]

[ Weiter ]

[ Zurueck ]

[ Weiter ]

[ Bearbeiten ]

[ Zurue ck ]

[ Weiter ]

[ Ende ]

[ default ]

Definition Deployment

Figure 5 — Levels of abstraction of models concerning BPMand enterprise SOA.



planning, and managing enterprise SOA in an integratedway (see Figure 6).

ADOPTION OF BPM WITHIN ENTERPRISE SOA

Top-Down: Business-Driven Approach

The top-down approach ( ) is suitable when BPM orenterprise SOA is used as a means to improve the enter-prise within business and IT on a company level (seeFigure 7). To do this, it is vital that both parties share aclearly documented vision and commitment.

Achieving a fundamental improvement like this is anontrivial and time-consuming task, especially in BPMprojects, if they are initiated by IT. The necessary busi-ness focus often is missing, and synchronizing withexisting BPM projects (those initiated by business butinitially unknown to IT) takes time and leads to a latermajor realignment of the IT-initiated BPM project.

When using a top-down approach, the team responsiblefor introducing BPM can proceed in the following (sim-plified) manner:

1. If there is no business architecture already in place, theBPM team identifies, names, and briefly describes a setof high-level business domains (usually about 10).

2. After this, the team identifies, names, and brieflydescribes a set of the most important businessprocesses (usually about 50-100) and links themto one or more business domains.

3. For each of these business processes, team membersidentify, name, and briefly describe activities (usuallyabout 10). The order of activities within a process or adetailed description with UML-like granularity is notdesired in this step.

4. The BPM team then identifies synergies by searchingfor similar activities in the overall set of processes,naming and defining these activities identically, anddefining composite services for these shared activities.

OrganizationProcesses

SOA DomainsSOA Services

ModulesClasses

TransactionsTables

FilesPlatforms

Infrastructure

MetadataRepository

BuBBusiness

BuBuBBuBuBuBBusBuBuBBuBu

rprise SOA

Enterprisrpriserpris

Software

System

Operational Systems Business Intelligence

Operational Applications Legacy CRMERP

Basic Services

BPM/BRM

ProcessPortal

DWH Mart

CompositeServices

ESB

Operational Data Stores

BAM/Process Process

KPIs

ETL

AnalyticServices

Data Warehousing

Monitoring Analysis

Enterprise Architecture

Enterprise SOA

Figure 6 — BPM, SOA, MDSD, and metadata.

Business

Organization

Methodologies

Architecture

Technology

People

SO

AEnte

rpri

se

StakeholdersMarket

ConditionsBusinessDrivers

BuBBusiness

BuBuBBuBu

rprise SOA


Software

System

As-Is Architecture

BuBBusiness

BuBuBBuBuBuBuBBusBuBuBBuBu

rprise SOA


Software

System

To-Be Architecture

BottomUp

TopDown

1

2

Strategy · SponsorshipBusiness Processes

Business Lines · IT OrganizationBoards and STCs

Skills · CultureRoles

IT/Business Alignment · IT Governance SOA Portfolio Mgmt. · Project Mgmt.

SOA Reference Architecture Functional Architecture

Runtime Engines/ContainersRepository · Middleware · ESB

Figure 7 — Adoption of BPM within enterprise SOA.


5. The team further fragments these composite servicesinto basic services and identifies synergies betweencomposite services using commonly shared basicservices.

6. The processes and activities are modeled in detail.

7. The BPM team transforms processes, activities, andcomposite and basic services into an executable form,potentially using MDSD, and adds implementationdetails.

8. The cycle of BPM and BAM is used for continuousprocess improvements; business architecture andother enterprise SOA artifacts are enhanced asneeded.

Bottom-Up: BAM-Driven Approach

The bottom-up approach ( ) is suitable when the pre-requisites of a business-driven approach do not applyor the scope is intentionally limited (e.g., for tacticalreasons) and implicit processes are the center of interest.

In this case, BAM can make implicit processes transpar-ent using the technical instrument of “probes” to analyzethe current status in a noninvasive manner. The businesscan analyze the existing application landscapes in com-bination with a process landscape, leading to a real-timeprocess dashboard. The results can be used as a basis forforecasting optimization potential and developing a cor-responding business case (i.e., for taking a top-downapproach and the further steps described above).

T-MOBILE’S VIEW ON BPM, SOA, AND MDSD

As a globally acting mobile network operator and ser-vice provider, T-Mobile serves an extremely competitivemarket. To be successful in such an environment, it isnot sufficient to be “just” flexible, agile, and efficient. T-Mobile’s mission is to be the most highly regardedservice company by adhering to three strategic buildingblocks:

1. Customer centricity

2. Superior network experience

3. Operational excellence

Operational excellence is the basis for creating customercentricity and a superior network experience. Thisrequires a reduction of complexity throughout the entireorganization, a tightened portfolio, and a stronger focuson the core business and its processes.

T-Mobile’s processes are increasingly complex, full ofdeeper interactions across systems, and dependent onmore collaborative activities between users. T-Mobile

has already addressed these issues with two major SOAinitiatives, but additional agility is still needed. Thatagility depends as much on supporting new efficienciesfor people as it does on liberating access to systems andservices. This is the role of BPM in the world of SOA; ithelps T-Mobile to attain a competitive edge throughrepeatable and predictable processes involving peopleand systems and to achieve compliance with organiza-tional guidelines.

The most important things to adapt are the processesthemselves. T-Mobile has found that if the processmodel is not transformed into executable artifacts, it isvery hard to map the business process to what is reallybeing run in production. Take, for example, a Webapplication. Some presentation components containparts of the process flow and business rule logic of theapplication, while business services build other flowand rule logic into supporting systems. If a businessdepartment needs to change a business process (i.e.,concerning the order of operations), it is hard to mapthe business requirement to the exact code that needsto be changed. This was one of the pivotal lessons of T-Mobile’s recent SOA initiatives. While T-Mobilefound that it is extremely helpful to have SOA basicservices in place that could serve as building blocks forapplications, this is not sufficient to become truly agile.The company learned that flexibility in the compositionof those building blocks is equally important. Providingthis flexibility is at the core of BPM, which allows modi-fications to be made in the business process flow inde-pendently of modifications to business rules and theimplementation of systems.

By embracing BPM, T-Mobile is about to documentmajor areas of its business, and T-Mobile's IT orga-nization will provide a method of formalizing andautomating business processes. These applications areprocess-driven; that is, all the code is triggered frombusiness-defined activity tasks. So the process really dri-ves the systems, directly enforcing the flow, tasks, andoperations allowed in the process. Applying BPM on topof SOA processes is a central means of reusing services.

Business process design — the first step of T-Mobile’sMDSD approach — provides a way to both model andanalyze business processes, thus improving the commu-nication across teams. With this information, businessanalysts have a powerful tool for clearly describingcomplex business issues. Business analysts, executives,line managers, and end users can each understandthe business issues and make recommendations forimprovements in business models. IT can then usethese business models to generate an executable processskeleton and enrich it with all required technical details,



such as service invocations. Once these processes arerunning, BAM will allow a comprehensive end-to-endanalysis of the performance of the processes and pro-vide the business with KPIs to measure the processefficiency. This closed loop enables T-Mobile to con-tinuously improve the service it offers to its customers.

BPM as seen by T-Mobile is more than just a softwaretechnology for designing, integrating, activating, andautomating business processes. It represents a frame-work to help enable change in the organization. BPMwill help T-Mobile innovate more easily by rethinkingand simplifying processes. As BPM has a number ofimplications for topics such as service portfolio manage-ment, service reference mapping, and service lifecyclemanagement, T-Mobile’s IT organization has groupedall those topics under one overall program calledBusiness Process Enablement (BPE). Combined withSOA, BPE will help T-Mobile to protect the investmentin its systems by reusing services. Understandingand designing business processes is a key policy ofT-Mobile’s BPE initiative. Furthermore, the implemen-tation of BPE will help to improve the alignment ofbusiness and IT within T-Mobile.

Michael Hartges started at T-Mobile in 1999 as team leader,Billing and Accounting Mobile Satellite Communication. In 2001,Mr. Hartges moved to T-Mobile’s International Strategy unit, wherehe was responsible for the synergy and integration programs the ITgroup conducted across Europe. Besides contributing to the definitionof a new international architecture reference model for T-Mobile, heconducted a global evaluation program to select a strategic partner forEAI. As T-Mobile started to implement a new IT organization acrossEurope, he moved to the newly set-up department of IT EnterpriseIntegration. Currently, Mr. Hartges leads the Centre of ExcellenceEnterprise Integration Services and is responsible for topics such asBPM, BAM, and B2B infrastructure. He leads the IT-wide BusinessProcess Enablement initiative, which intends to make T-Mobile’sIT organization ready for the “BPM world.” Mr. Hartges livesin Cologne, Germany, and can be reached at [email protected].

Dirk Krafzig has worked for more than 15 years as an architect, con-sultant, and manager in the IT industry, both for IT service providersand ISVs. Dr. Krafzig focuses primarily on the insurance industry,particularly the life, health, and P&C areas, where he has managedcomplex projects and developed modern architectures. Since 1996,he has focused on enterprise architecture management and SOAs.Dr. Krafzig holds an MSc and PhD in computer science. With DirkSlama, he is coauthor of Enterprise SOA, one of the best-selling SOAbooks on Amazon.com for three years running. Dr. Krafzig lives withhis wife and two children in Dusseldorf, Germany, and can be reachedat [email protected].

Since finishing his studies of business management in Cologne,Germany, Michael Kunz has worked for eight years as an architect,consultant, project manager, and general manager in the IT industry,working both for IT service providers as well as independent softwarevendors (ISVs). His main vertical focus is in the insurance industry,where he worked for several years in the life and property and casualty(P&C) areas, managing complex projects and developing modernarchitectures. Mr. Kunz has been focusing on enterprise architecturemanagement and SOA since 1997. Mr. Kunz lives in Cologne,Germany, and can be reached at [email protected].

A graduate in civil engineering, Florian Mösch is a VP of EnterpriseIntegration & Architecture at T-Mobile Deutschland GmbH. Heis responsible for all integration architecture matters and the corre-sponding technologies and standards. Mr. Mösch started his careerat Digital Equipment Corp in Cologne, Germany, and in 1992 joineddigital mobile radio DeTeCon in Bonn, Germany, where he wasresponsible for the project’s PC and server technology in the datacenter. In 1993, T-Mobile was founded out of this and other projects.In the beginning, Mr. Mösch set up and managed the departmentmanaging the system operation office communications and the systemdesign team. In 1999, he took over the leadership of the main depart-ment IS Engineering Services in IS application development. From2004 on, he has specialized in integration technologies. Among others,Mr. Mösch was responsible for implementing a T-Mobile-wide EAIbackbone. In March 2005, he became responsible for the Europeanunit of T-Mobile associations for Enterprise Integration. Besides theoperative responsibility for development and deployment, Mr. Möschalso looks after all strategic aspects of integration for the European T-Mobile Group. As Deutsche Telekom moves toward convergence forfixed and mobile customers in Germany, he is involved in architec-tural and integration topics on the Telekom Group level. Mr. Möschcan be reached at [email protected].

Dirk Slama holds an MSc in computer science from TU Berlin, aswell as an MBA from IMD International in Lausanne, Switzerland.Mr. Slama has more than 12 years of international IT experience, hav-ing worked in the US, the Asia Pacific region, and Europe. Mr. Slamahas helped customers such as Boeing, AT&T, NTT DoCoMo, andHalifax Bank of Scotland to implement large IT projects. With DirkKrafzig, Mr. Slama is coauthor of Enterprise SOA, the 2004 bookthat laid the foundation for enterprise SOA. Mr. Slama lives in Berlin,Germany, and can be reached at [email protected].

Thomas Stahl holds a degree in computer science and is ChiefArchitect at b+m Informatik AG. One major focus of his profes-sional life is MDSD, particularly in the context of SOA and BPM.Mr. Stahl gained long-term project experience in this field and is theauthor of Model-Driven Software Development: Technology,Engineering, Management and founder of the open source frame-work openArchitectureWare. Furthermore, he has substantial experi-ence in enterprise architecture, project and product management,modern IT technologies, and several vertical domains such as banking,insurance, telecommunications, automotive, and healthcare. Mr. Stahllives near Kiel, Germany, and can be reached at [email protected].

THE ENTERPRISE INNOVATION CHAIN

The shift from an industrial to a knowledge-based econ-omy — envisioned by Alvin and Heidi Toffler, PeterDrucker, and other top thinkers on the verge of the 21stcentury — is quickly materializing. The shift is clearlymarked by the rising importance of innovation andinnovation management in the vocabulary of manymodern enterprises, as well as the extension of thenotion of innovation beyond the traditional area of“invention.” While ownership of an intellectual asset —such as a successful technical standard, a breakthroughtechnology, or a drug formula — still remains one ofthe most valuable sources of advantage, this advantageis complemented by three other forms of innovativeactivity:

1. Value innovation

2. Management innovation

3. Business model (strategic) innovation

These three categories form the links of an enterpriseinnovation chain — a chain of interrelated activitiesthat give businesses the ability to use change as a com-petitive weapon.

In this article, we would like to discuss how the innova-tion chain can be supported by applying architectureand governance solutions within the BPM domain. Wewill focus our attention on two areas: value innovationand management innovation. As a recent study byCutter Consortium [3] shows, these are the two mostfrequently explored parts of the innovation chain.

Value innovation is a category primarily related to therelationship between a business and its market. As thenature of market offerings changes from products toservices to — even further — experiences, all businessesare subjected to the growing pressure of value erosion.Any successful, unique market offering gets quicklyreplicated by market players, leaving a relatively shorttime window for value innovators to thrive on theiruniqueness. In order not to surrender to the forces ofcommoditization, one needs to be able to provide a

constant stream of new service capabilities and attrac-tive new aspects of the customer experience.

Value innovation may exploit inventions as the sourceof new value, but most of the time it relies on estab-lished technologies and standards. The essence of anyvalue proposition can be seen as a combination ofattributes that define product/service characteristics(quality) from the customer perspective. Value innova-tion relies on finding an appealing recombination ofthese attributes or changing the dimensions that definethe competitive landscape. For example, adding twonew dimensions to traditional TV — interaction andtime independence — creates a whole new range ofinteractive TV products and services (see Figure 1).

Often, changes in a customer value proposition demandsome change in the way the value is delivered by anorganization, which affects business processes, cus-tomer relationship practices, and sometimes even keyelements of the business model and organization. The“creativity engine” of an enterprise (value innovation)has to be enabled by the flexibility of its “executionengine” (achieved through management innovation).What makes this relationship most challenging is thefact that, in most organizations, the flexibility requiredto achieve value innovation must not compromise oper-ational efficiency, which has now become a given inmost industries.

FLEXING YOUR PROCESSES

Now comes a question: how can competitive levels ofefficiency and flexibility be achieved simultaneously?Business strategy analyst Thomas Davenport offerssome interesting insight on this question. In a 2006article in the Harvard Business Review, Davenport sug-gests that efficiency and flexibility of processes can beachieved by radical process commoditization [1]. Thisrequires development of process standards that enable“plug and play” sourcing of activities and processes.The process activity and flow standards Davenportenvisions are already being developed and maintained


Adaptive Process Management Architecture: EnablingEnterprise Innovation by Marrying SOA to Business Rulesby Borys Stokalski and Marcin Strozanski

ADEPTLY ADAPTIVE



by various industry groups, such as the SupplyChain Council and the TeleManagement Forum.Standardization bodies such as SCOR and APQC arecurrently defining process performance standards thatattempt to normalize a way of measuring and evaluat-ing various performance aspects of processes. Processmanagement standards define the processes that enablecontinuous process improvement. An obvious set ofsuch standards is the ISO 9000 norms related to qualitymanagement or the excellence model defined by theEuropean Foundation for Quality Management (EFQM).

Yet as the experience of the IT industry shows, processcommoditization comes at a price. It makes sense in areaswhere the best practice is well established, process break-throughs are unlikely to happen, and the product deliv-ered by a process is, to a large extent, a relatively simplecommodity with stable requirements. In areas wherechanges in business processes are an essential part ofthe innovation chain, however, this is hardly the case.Borrowing the rhetoric of the Agile Manifesto, one cansay that to support enterprise innovation, we clearly needa better way of designing and implementing efficient yetflexible business processes. A way that champions:

People, skills, and competencies over process rolesand the chain of command

Working processes over automated routine

Delivering value for customers over maintainingservice levels

Following customer needs over following procedures

Such a “better way” is by no means a ready-made solu-tion. The main challenges in adopting agile processes lie— as in agile project management — in the established

ways of thinking, the “chain of command” mentality,and a common belief that routine, risk avoidance, andobedience have more business value than creativity,opportunity taking, and responsibility. Such challengescan be hardly overcome by technology alone. Still, tech-nology has an important role in supporting those whowant to seize the opportunity of adaptive processmanagement.

EMBRACING ADAPTIVE PROCESS MANAGEMENT

If we recognize the opportunity for adaptive processmanagement to enable the enterprise innovation chain,the next question is, what capabilities have to be createdin the enterprise architecture to deliver the promises ofagility? We offer the following four essential capabilitiesas the baseline requirements for an architecture sup-porting adaptive process management:

1. The capability to deliver new activities, flows, andrules quickly and effectively, by adopting predefinedprocess automation components and related userinterface components, integrated with the coreenterprise information assets.

2. The capability to plan improvements to existingprocess automation components and design newcomponents so that resulting activities, flows, andrules meet the performance and quality criteria ofthe business. This capability enables rapid processexperimentation (prototyping).

3. The capability to control business activities so thatany business performance failure risk can be iden-tified and acted upon before it materializes into a

Video StoreEnhanced

Video Store Participation

TV + Dialog TV Agora TV

On Demand

Navigation Dialogue Collaboration

Broadcast

Level of Interaction

Tim

e In

dep

enden

ce Classic VoDVoD + Rankings,

Discussion Groups, Education

Video Blog,Collaborative TV

Teletext Opinion Polling Video Chat

Figure 1 — Creating new product opportunities by extending performance dimensions.


customer-related, employee-related, or financialproblem.

4. The capability to support the management of theprocess changes and disruptions introduced bynew processes, new process content, or processmodifications.

These capabilities are shown in Figure 2, whichpresents the conceptual framework of adaptive proc-ess management.

For those who are willing to take the risk of being pio-neers in this exciting domain, there are a number oftechnologies and approaches that can be integrated intoa reasonably consistent platform to support adaptiveprocess management. We need to stress here that we areby no means talking about an out-of-the-box solution.Companies that seek tools to support their quest foragility will need to perform some nontrivial conceptualand engineering work in both the business and ITdomains of enterprise architecture to make such aplatform a sound reality.

The adaptive process management platform needs thefoundation of a services portfolio built in accordancewith the principles of service-oriented architecture(SOA). Corresponding architecture patterns (Managedservices portfolio, Service-based assembled application) havebeen defined in a Cutter Consortium Executive Report onenterprise architecture roadmapping [2] and presentedin an article on SOA governance in a recent issue ofCutter IT Journal [4]. Important components of the adap-tive process management platform include:

Business rules engines, which are specialized mid-dleware and management tools that can help theorganization define its processes as a set of interre-lated rules, expressed in business terms and inte-grated with the enterprise services portfolio, ratherthan as a prescribed and rigid workflow.

Business process management (BPM) engines andtools, which are specialized middleware and manage-ment tools that can help an organization to quicklyassemble services implemented in its enterprise ser-vices portfolio into an automated process and thenorchestrate its execution. Such tools pave the wayfor the prototyping of business processes in a waysimilar to application prototyping.

E-learning and content management tools thatenable large-scale deployment of new activities,flows, and rules supported by process automationcomponents.

Business intelligence components, such as oper-ational data stores combined with specialized data-marts for business metrics collection and monitoring.In high-volume/high-speed processes, the challengeis to keep the monitoring data synchronized with theactual progress of business processes in real time.

STEP-BY-STEP APPROACH: A CASE STUDY

Our client, Telekomunikacja Polska (TP) S.A., a mem-ber of a large telecommunications group, is currentlyconsolidating the operations of its fixed and mobile

Adaptive Process Management

Managed Services Portfolio

Manage Control Design/Deliver/Improve

Process ChangeManagement

Process MonitoringRapid Process

PrototypingService and Process

Components

Skills ManagementBusiness Event

MonitoringService/Process

Modeling and DesignRule Modeling

and Design

Process ConfigurationManagement

Service-LevelManagement

Service/ProcessAssembly and Orchestration

Rule Set Management

E-Learning Platforms Real-Time Analytics Service Delivery StandardsAutomated Business Rules

and Rules Engines

Req

uire

men

tsC

once

pts/

Pra

ctic

esTe

chno

logi

es a

nd S

olut

ions

Achieved by …

Supported by …

Figure 2 — The conceptual framework of adaptive process management.



subsidiaries in Poland. The company’s experience offersa good example of an evolutionary approach that mapsthe road to adaptive process management.

In order to progress on this road, TP started by identify-ing the basic “chunks” of business activity and theirsupporting information architecture. To transform thesechunks (services) into a services portfolio by applyingarchitecture patterns and the standards of SOA, thecompany had to take three major steps (see Figure 3).The first step — relatively straightforward — was tostart delivering business functionality as standardizedservices. Increasing demand for services required anintegrated environment for large-scale delivery, deploy-ment, and reuse of services — step two. Finally, toensure proper alignment of the services portfolio, ITgovernance and management practices needed toaccommodate the challenges of service managementand governance.1 Over the last three years, within thecomplex IT environment typical for telecoms, TP hascreated a services portfolio that integrates several hun-dreds of services and composite applications.

This portfolio, along with a few other strategic compo-nents (CRM, billing and provisioning applications, etc.),serves as the cornerstone and building blocks for thebusiness functionality. Deregulation and convergenceof digital communication create a growing pressurefor the business to extend the product portfolio wellbeyond traditional services into the realms of Internet,entertainment, interactive media, and enterprise infor-mation infrastructure.

TP’s sales process for new products has been for sometime supported by a range of bespoke IT solutions builton the basis of a proprietary technology platform by asmall local vendor. These solutions handled productand order management and interfaced with provision-ing processes, largely in isolation from the remainingpart of the enterprise architecture and its routines. Thisapproach offered business users so much flexibility thatthey have been quite willing to confront corporate ITgovernance standards instead of letting the enterprisearchitects decide on how and when the required busi-ness functionality is delivered.

The growth of business related to new productsinevitably led to a situation where the isolated solutionbecame a problematic legacy and a bottleneck in majorIT releases. The company has decided to migrate theproprietary system so that its functionality is deliveredby a set of orchestrated services added to the managedservices portfolio based on the cornerstone applicationsin the enterprise architecture: CRM, billing, provision-ing, and the services portfolio built on top of theEnterprise Service Bus. Now, an important architecturalchallenge was how to migrate the current functionalityinto a relatively more complex (yet at the same timemore supportable) environment while preserving theflexibility offered by the current solution. To achievethat, architects have decided to take advantage of thefact that the integration technology vendor (whoseproduct has been used to build the services portfolio)has extended its platform by incorporating a newly

1For more on this topic, see [4].

Service

Delivery

Service Management

Service Integration

Business ProcessAutomation

Business RulesAutomation

AdaptiveBusiness Processes

ManagedServicesPortfolio Exception Handling

Inventory Update

Service Activation

Service Configuration

Conversion from Canonical to Native

OSS AtomicProcess

EAI ConvertionCatalog

OSS AtomicActivation Service

(Automatic)

NetworkInventory

OSS ManualProcess

Figure 3 — A step-by-step approach to adaptive process management.


acquired leading business rules engine. The idea hasbeen to use the rules engine as the main vehicle for ser-vice orchestration and to employ rules and rule sets asthe main interface in order to introduce changes in busi-ness processes relatively quickly and easily, thus reduc-ing the need for complex programming. Figure 4 is avisualization of the resulting architecture.

The results achieved in a relatively short time framehave been quite promising. Order capture, validation,and management — the core set of business processes— have been migrated into the new architecture infour months. The resulting solution includes a numberof services integrated with core applications and a setof approximately 300 business rules. The project alsodelivered some insights and some good and bad prac-tices related to this approach to process automation. Toname the few most important:

Rule sets need architecture. Business rules automa-tion technology may help create very flexible appli-cations if used correctly. It is possible to employbusiness rules so that process threads are adapting thesequences of actions and events to the specific processgoals and constraints, creating more efficient andaccurate responses to business events. But the rulescan also be heavily misused if treated as just anotherprogramming environment. Such an approach yieldsrules and rule sets that are heavy, inflexible, and con-tain intricate internal relationships that become amanagement nightmare. A well-designed architectureis needed for rule sets as for any other programmingartifact, and some good old principles of modulardesign — such as loose coupling and high cohesion —should be applied rigorously.

Rules enable (and are enabled by) governance.The separation of business rules from the

underlying application logic and architecture givesthe business process managers a uniform way to intro-duce changes into a business process. But this canonly be seen as a benefit if the business managers arewilling to use the concept of rules to govern changesin the way the business operates. While it seems atthe first glance that there can hardly be anything morefamiliar to a business than business rules, the commonunderstanding of this concept is often far removedfrom the discipline required by rule automation. Onthe other hand, if the business internalizes the conceptof business rules, decisions related to policies andprocesses (such as product management, customercare, sales, and/or logistics) can be instantly auto-mated, which sounds like IT governance nirvana.

The technology is somewhat mature. There are manybusiness rules engine vendors that offer very reliableand battle-proven products. But as integration tech-nology vendors are currently introducing businessrules automation technologies into their offerings,some performance and reliability issues may be expe-rienced. To manage this risk, a large-scale deploymentshould be preceded by technical pilots that will iden-tify the most appropriate architecture patterns to beused in heavy-duty, mission-critical applications andprocesses. Organizations should seriously considerpostponing any large-scale rollout until the vendorresolves critical integration issues.

EXPLORING THE OPPORTUNITIES

The project described in the previous section allowed usto explore an important adaptive process managementopportunity. Our experiences lead us to believe thatthere are many areas where similar adaptive process

Customer Self CareCRM

Managed Services Portfolio

Enterprise Service Bus

Order ManagementEngine

Order ManagementOrchestration/BPM

Order Validation

Front-End Applications

Event Processing

Rule ProcessingRules Engine

Figure 4 — The high-level concept of the adaptive process management architecture at TP S.A.



management is a business imperative. The first one isautomated customer-facing processes (customer self-care). For numerous types of services, customers canperform various tasks, such as bill settlement, purchase,customer support request, or account management usingall kinds of online interfaces, from call centers to theInternet to short text messages sent by mobile phone.The complexity of customer issues varies, as does theirurgency or the degree to which they provide businessopportunity (up-selling, cross-selling) or risk (customerdefection, fraud). On the other hand, customers’ expecta-tions of receiving “individual treatment” are increasing.Therefore, the idea of personalization gets transformedfrom the ability to customize a few elements of thecommunication interface used by the customer to a full-blown adaptive customer care process — that is, theability to optimize activities and communications inresponse to various customer-related events.

Another important driver of adaptive process manage-ment is the increasing importance of product innova-tion seen in the services industry, financial services, andtelecommunications. As we have already stated, thissituation forces these organizations to search for newways to design, test, and implement services. Productmanagement specialists need new capabilities to spotthe emerging opportunities in customer behavior; plannew products along with their promotional, sales, andcustomer service processes; then quickly implementand improve them, often involving business partnersin product-specific operations.

Finally, despite the commoditization of businessprocesses, such emerging standard flows and activities,along with standardized performance models, inviteprocess innovation at a higher level of the supply chain.In modern business, sourcing decisions become partof operational management, and the ability to quicklytake and implement these decisions can be a powerfulinnovation enabler. Meanwhile, however, the diversityof such networks of collaborating suppliers increases,and businesses that want to have good control overtheir logistics, quality, and delivery have to adapt theirsupply chain management processes to the specifics ofvarious independent business partners. The less a valuenetwork is dominated by a single source of authorityand control, the bigger the demand for highly adaptivesupply chain management processes.

Regardless of the various motivations that may standbehind adaptive process management initiatives, webelieve that these initiatives require a careful step-by-step approach. Most of them will require a significant,

well-orchestrated effort affecting various parts of theentire enterprise architecture, and as such, they shouldbe driven by a clear roadmap that synchronizes the busi-ness goals, technology opportunities, and action plan.

REFERENCES

1. Davenport, Thomas. “Competing on Analytics.” HarvardBusiness Review, January 2006.

2. Kiepuszewski, Bartosz, Michal Paluskiewicz, Borys Stokalski,Sebastian Konkol, and Maciej Ruszynski. “Applying EARoadmapping: An SOA Roadmap.” Cutter ConsortiumEnterprise Architecture Executive Report, Vol. 7, No. 9,September 2004.

3. Stokalski, Borys. “The Enterprise Innovation Revolution:Part I.” Cutter Consortium Business Technology Trends &Impacts Executive Update, Vol. 8, No. 5, 2007.

4. Szabelak, Piotr, and Jan Topinski, with Borys Stokalski.“The Tao of Service-Oriented Architecture Governance.”Cutter IT Journal, Vol. 20, No. 6, June 2007, pp. 34-43.

Borys Stokalski is a Senior Consultant with Cutter Consortium’sBusiness-IT Strategies, Enterprise Architecture, and Innovation &Enterprise Agility practices. He is VP of Infovide-Matrix S.A., a Polishcompany specializing in architecting and implementing IT-based busi-ness innovations. Infovide, which is the exclusive representative ofCutter Consortium in Poland, is ranked among the top CSI (Consulting& Solution Implementation) organizations in that marketplace.

Mr. Stokalski began his career in 1985 as a research worker and thenas a lecturer in the area of human-computer interaction at the WarsawUniversity. He takes an active part in Infovide-Matrix initiatives tar-geted at new service areas and consulting products, such as adaptivebusiness strategies and architectures, knowledge management, collabo-ration architecture, and training programs for IT managers. He fre-quently shares his experiences and insights through articles andconference appearances on topics such as innovation management,the business impact of technology change, and enterprise architecturemanagement. Mr. Stokalski can be reached at [email protected].

Marcin Strozanski is one of the leaders in the Enterprise ArchitectureSolutions competency center of Infovide-Matrix. He is an experiencedarchitect of distributed, mission-critical systems and a senior expert inareas such as distributed architectures, SOA, and EAI. Mr. Strozanskibegan his professional career on an R&D team responsible for develop-ing new IT architectures and solutions supporting the strategic trans-formations of Telekomunikacja Polska (TP) S.A., the leading Polishtelecom. Since joining Infovide in 1998, he has been involved as anarchitect in a broad range of projects related to complex SOA/EAI plat-forms for clients in the telecommunications industry. He takes an activepart in shaping the Infovide-Matrix strategy and supports other consul-tants in the Enterprise Architecture Solutions team as a coach and men-tor. Marcin Strozanski can be reached at [email protected].

The IT industry is remarkably adept at making, everycouple of years, hyped-up claims that some new tech-nology will answer all the IT needs of every organiza-tion. In doing so, this latest panacea will allow legacyIT assets to be retired (or possibly refactored — i.e.,recycled rather than trashed). Business process manage-ment is the hyped technology of the moment, promis-ing unprecedented business agility, incomparable timeto market, and lower operating costs. With such posi-tive impacts on business, time, and costs, no benefitis missing!

Schlumberger, the oilfield services company, is cer-tainly no stranger to enterprise architecture (EA) efforts;in fact, we started looking at EA in terms of businessprocesses several years ago. Wanting to learn if the newBPM approach merited a significant investment, thecentral IT organization conducted a hands-on, proof-of-concept project. In this article, I provide highlights ofthis investigation and the lessons learned.

FROM APPLICATION INTEGRATION TO PROCESS INTEGRATION

IT organizations, regardless of the organizational modelthey follow, tend to respond to business needs by creat-ing new applications to fulfill the requirements pre-sented to them. This typically results in a proliferationof disconnected “silo” systems. There are about 470 dif-ferent applications at Schlumberger, and this numberis small in comparison to what we have seen at othercompanies. To bring some order to our business appli-cations, and following an assessment by a global ITconsulting firm, we developed an EA blueprint andintroduced, on top of EA best practices, a commonmiddleware product for enterprise application inte-gration (EAI). There are about 600 information flowstoday in Schlumberger that deliver data integrationbetween applications. These are critical IT assets ofthe company, as they start enabling — on top of our

business applications — the implementation of end-to-end business processes such as “Procurement toPayment,” “Opportunity to Cash,” “Service Delivery,”and so on.

If we look at business processes rather than at individ-ual applications, however, we can often streamlinethese processes and implement linkages that simplifythe user’s job and improve the quality of the data (e.g.,by eliminating multiple entry). According to Wikipedia,BPM is a discipline “encompassing methods, techniquesand tools to design, enact, control, and analyze oper-ational business processes, involving humans, organi-zations, applications, documents and other sources ofinformation.”1 The intent of BPM is to introduce a shiftin the way we do integration, from today’s applicationfocus to a process focus. Indeed, many of the problemsthat surface when we try implementing end-to-endprocesses are caused by the inherent gaps, if not bound-aries, between disparate applications — gaps that atsome point cannot be tackled by just using EAI. EAIcreates bridges between applications, but if applicationsare separated by an ocean rather than by a river, weneed more than a bridge … and creating yet anotherapplication to fill the gap is often the wrong approach.

BPM SUITES

A BPM suite aims at integrating numerous solution com-ponents into a single, consistent platform that offers arationalized interface to its users. A BPM suite is com-posed of a set of modules that support the BPM lifecycle(see Figure 1):

Process modeling by a business analyst

Process implementation by an architect and an IT developer

Process execution by the orchestration engine

Process monitoring and optimization by thebusiness analyst


Are BPM Suites Ready for Prime Time? Lessons from a Proof-of-Conceptby Olivier Brousseau

FOOLS RUSH IN

1See http://en.wikipedia.org/wiki/Business_Process_Management.



According to IT market analysts, BPM is a disruptivetechnology, just as enterprise resource planning (ERP)was in the 1990s. It is understood that the market ischanging, with many mergers and acquisitions stillto come. Nevertheless, in today’s market we candistinguish:

Companies coming from the EAI space, which areusually very strong with their EAI tools and offer avery technical platform

Companies coming from the application server space,whose strength is usually in providing scalable andperforming solutions (in other words, they have astrong ability to execute)

Companies coming from the workflow space, whichusually provide a strong BPM orchestration engineand repository, with templates and a framework

Companies coming from the ERP domain, whosesolutions usually have strong connections to theoriginal ERP package

A BPM suite is usually marketed as a means for anorganization to reduce the gap between its businessand IT functions and to reposition its IT infrastructureas process-centric rather than application-centric. Thepromises and expected benefits of BPM suites arenothing short of miraculous:

Fast development and improved time to market.The BPM suite will provide IT analysts with themeans to accelerate development, while allowing thebusiness analysts to modify their business processeswith minimal involvement by IT.

Lower systems implementation risks. The suitewill provide a platform to model and implement abusiness process and then to make incremental andevolutionary changes to that process.

Increased adaptability, flexibility, and agility.By wrapping the core functionality of existing appli-cations and processes, the suite will make themreusable in new processes without affecting thelegacy system(s).

Lower business costs. The BPM suite will reduceoperating costs by automating repetitive steps, inte-grating application systems as needed, and support-ing complex decision making.

Better governance and compliance. The system willforce its human actors to follow the rules defined inthe process — controlling the ways in which deci-sions are made and modifications to the processesare introduced — and provide auditing capabilitiesfor ongoing and past activities.

Better customer service. Ultimately, the BPM suitewill enable better customer service by shorteningcycle times and making it easier to respond in atimely manner to variations in customer behavior.

Presented with these claims, the question we facedwas: if we agree that we need BPM, is a BPM suitethe solution?

THE CHALLENGE: A BPM SUITE PROOF-OF-CONCEPTPROJECT

To understand and measure the marketed benefitsof a BPM suite, we challenged five suppliers to imple-ment a simplified system for “intercompany invoice”automation — a process we call the Internal ServiceTicket (IST).2 The existing IST is a human-to-systemprocess that requires human collaboration (informa-tion exchange, approval processes) as well as systemautomation (invoice creation in the financial system,approval process lookup in the supply chain manage-ment [SCM] system, etc.). Actors in the IST process areoperations managers, business analysts, accountants, taxmanagers from the sending and receiving parties, andthree key systems: the financial ERP system, a learningmanagement system (for training invoices), and theSCM system. The IST is in fact a simple process: a proj-ect for an ad hoc implementation by a contractor took

Process Modeling

ProcessImplementation

Monitoring andOptimization

ProcessExecution

Figure 1 — The BPM lifecycle.

2Here “intercompany invoice” really means an interdivision invoice, rather than an invoice to our clients. The IST process is about inter-nal cross-charges that occur between two entities of the company for a delivered service such as training — a process that is necessarybecause we are a global corporation with many separate legal entities.


three months from the time the process to be built wasdefined until the time the pilot went live (see Figure 2).

We issued our “simplified IST” challenge and werepleased that five key BPM suite vendors (some thatwere pure BPM players and some that came from theEAI world) were willing to demonstrate the value oftheir solutions in this manner.

Competition Highlights

We used a combination of evaluations to assess thestrengths and weaknesses of the BPM suite:

Strategy and product roadmap briefing. We askedvendors to conduct an in-depth product presentation;to brief us on their business strategy, compliance withrelevant standards (specifically the Business ProcessModeling Notation [BPMN] and the Business ProcessExecution Language [BPEL]), and their short-termdevelopment roadmap; and to provide references.

Demonstration of a first IST implementation. Weasked vendors to come with a first implementationof the process and run a demonstration. They weregiven access to Web services that simulated the ITsystems required for the IST process integration.

Construction quotation. We asked vendors to pro-vide a quotation for the construction of limited locallogistics processes using their BPM suite. They wereinvited to not just rely on their own professionalservices, but preferably to demonstrate their partner-ship with IT services companies.

Live demonstration of process changes. We askedvendors, during their demonstration of the ISTprocess, to perform one or two process changesthat consisted of adding an information item inthe cross-charge form and adding an approval stepto be performed by the requester’s manager.

Pricing. We asked the vendors to introduce theirpricing schemes and to present cost figures on theinvestments we would have to make to supportprocess implementation (pricing per user, per CPU,per process instance, etc.).

The vendors demonstrated their suites all along theBPM lifecycle. In the context of implementing thehuman-to-system workflow, we assessed the benefitsof the five BPM suites with their core capabilities ofmodeling and building processes; storing, managing,and auditing process instances; and generating reports.Using these same lifecycle steps, I present some of ourfindings in Table 1.

After completing these evaluations, we asked for:

A time-boxed IST prototype. We selected the top twoBPM suite vendors out of the five and asked them toimplement the full IST project requirements withworkflow variations (allocations and shared costs,full credit against an invoice, partial credit against aninvoice). This was to be done inhouse, within stricttime and resource constraints (i.e., in four weeks andwith up to two full-time staff equivalents).

Sobering Results

At the end of this exercise, we had to conclude that atthis stage in the development of the concepts, methods,and tools, a BPM suite has a high startup cost whileoffering limited opportunities.

Despite their richer and more complete applicationdevelopment environment, BPM suites were not able todemonstrate time-to-market benefit, nor any agility atall in terms of making rapid changes or corrections. Werealized that BPM suites are not yet mature. There is aclear lack of best practices — not just to the extent thatcan be expected of any new discipline, but also a lack oflessons learned from other previous techniques (objectorientation, frameworks, components, debugging, etc.).As a result, BPM implementations created with suchsolutions are today at risk in terms of maintainability —which is, incidentally, the basic form of agility that one

Get IST Number

Create IST Invoice Show Error

NOK

OK

Review Tax Settings

NOK

OK

IST Serviceand Cost

Accountant

Tax Manager

Accountant

Master DataValidation

Notify ReceivingParty

Figure 2 — The Internal Service Ticket (IST) process.



is after in IT. With maintainability at risk, the agilitywe’re after may not be there at all.

The scope of BPM suites is very large — they proposetools that span across numerous distinct areas of IT(user interface, application logic, business logic, humanand system workflows, monitoring and business intelli-gence, integration, governance, etc.). This results in animmature marketplace with a diversified populationof suppliers and solutions that do not meet integrationchallenges. BPM suite vendors are still elaborating theirproducts and pursuing ambitious roadmaps while

trying to better unify the different technologies thatcontribute to their offerings.

BPEL is a standard that is intended to allow “program-ming in the large” (writing long-running asynchronousprocesses), but it is already facing limitations in doing so.BPM suite vendors are trying to build a shell on top ofBPEL and to extend it with additional features to fill thegap. Even if each vendor claims to be BPEL-compliant(which is a dubious claim since the limitations of BPELitself are resulting in a marketplace where we have manyflavors of BPEL), each one implements it differently. This

FindingsLifecycle Step Theory

Process Modeling• Modeling• BPMN standard• Simulation• Interface with design

The modeling tool is used by business analysts to develop the procedural definition of their business processes. Here, compliance with the BPMN standard is key, as well as integration with the design and development of the process.

The “business case” for doing process modeling is missing. Is the model a design or draft implementation? Is it a representation of the business requirements? Or is it just a drawing that helps achieve a common understanding between the business and IT?

Process Implementation• Graphic design• Code or no code• User interface design• Business rules• Integration• BPEL

Through a rich integrated development environ-ment (IDE), vendors invite us to change the way we do things: zero-code approach, drawing and drag-and-drop only, lots of information mapping, and so on. Business rules abstract business policies and decision tables from the underlying applications and make available more flexible process changes.

In fact, the implementation phase is neither easier nor more agile — at least not yet. There is no clear buy-in by IT services companies (hence limited resources to assist the customer). The live process changes failed completely, and the time-boxed implementation was not a true success either when compared to the ad hoc solution that was already in place and was developed without a BPM suite. Coding best practices (object orientation, components, frameworks, etc.) were too quickly abandoned, putting the BPM suite–based implementation at risk in terms of maintainability, robust-ness (no compilation, poor debugging), and agility.

The link between the details of the business model and the process implementation is not clear. Indeed, during the implementation phase, extra technical artifacts that are not visible to the business must be added and managed (error handling, looking for the master data, etc.). The BPM suite does not guarantee that the map-ping between the two levels will remain intact over time, thus raising the risk of breaking the claimed alignment between the business and IT.

Process Execution• BPEL engine• Business rules engine• Integration engine

Monitoring and Optimization • Reporting• Dashboard• Search• Real-time business activity monitoring (BAM)

Process execution is delivered by the orchestra-tion engine, which coordinates the sequencing of the activities and steps (system and manual) according to the flows and rules in the process model (BPEL).

The vendors may be compliant with BPEL, but the promises of BPEL are not there. Designing the proc-ess in one BPM suite, exporting the design in BPEL, and executing the process in another BPM suite is just not possible today.

A BPM suite supports the analysis of data produced during process execution. Here, capabilities range from reporting to online analytical processing, graphical user dash-boards, and BAM. These are real-time systems with proactive alerting.

The process implementation had clear limitations, among them its inability to stick to the original busi-ness model. In fact, what is monitored is what is implemented, not what was modeled at the earlier stage.

Table 1 — Findings from the BPM Suite Evaluations


results in a high risk of not being able to change orches-tration engines once we start BPM implementation.

RECOMMENDATIONS FOR THE “BPM ROUTE AHEAD”

At Schlumberger, we believe that BPM requires newprocesses around governance and a significant develop-ment effort in order to start delivering business value.While creating these processes is a risky endeavor,attempting to implement BPM without them would beeven riskier.

The goal of BPM is to achieve business agility by map-ping business processes, from a customer or user stand-point, into a context where they can be iterativelyoptimized and adapted to changing business require-ments. BPM is a clear opportunity for us to refocus ITon the business processes, and the priority effort shouldbe on educating the business about the potential of thisapproach. For example, we need to communicate that itis not necessarily effective to replace a legacy applica-tion in an acquired company with a new one; rather, itis better to look at the process, see how to adapt it to thenew division, and roll it out. This process integrationapproach requires ownership at the CIO level, but alsoa willingness on the part of senior business managers tolearn about this vision and become cosponsors of thisinitiative.

Process modeling should become a recognized disci-pline and should be integrated into the project lifecycleprocess. Significant efforts are required to move froma conception of modeling as “the nice drawing thing”to leveraging the value of business modeling throughproper articulation with requirements managementand with the IT architecture. Business modeling can sig-nificantly improve the management of IT requirementsby offering a common representation that speaks toboth the business and IT. Indeed, too often we get lostimmediately in the details of a potential solution or itsunderlying technology, without looking at where thesolution fits into the overall strategy and the way inwhich we want to work and improve the current situa-tion. Business modeling can also become the first inputfor designing the solution architecture and identifyingwhich IT assets can be reused, which ones can be modi-fied, and which ones need to be built (e.g., in a service-oriented architecture approach). In the end, with proper

guidance, business modeling should enable the ITproject to be WYSIWYG ready. That is, what you see(business process model) is what you get (the IT imple-mentation after the journey is finished).

BPM is not about having a new single or unified typeof platform to build and support the execution of thenext generation of applications (composite applica-tions). In fact, attempts by some BPM suites to captureand implement specific application user interface andtechnical logic are questionable — other platforms(.NET, J2EE, packaged applications, ERP, etc.) aremuch more suitable for this purpose. Since the objec-tive of our proof-of-concept was to look at BPM suitesand their promises, we looked at a BPM suite as a fifth-generation language (5GL) without reuse or any inte-gration with other technologies. The complete softwarestacks provided by each of the BPM suite vendors didnot meet our expectations in terms of time to market,agility, or software maintainability because of a lackof proper technical or architectural governance.

In our view, a clear separation of concerns is required.A BPM suite should really drive the orchestrationof the tasks of the process (i.e., handle task dependen-cies, synchronization, and tracking) but not the tasksthemselves, which can be left to a legacy system anddelivered through proper integration using standarddevelopment technologies. As a result, following anSOA approach, the BPM suite should offer task manage-ment services in the context of IT-supported processes.Examples of BPM services are: “Where am I in thisprocess?”; “What is the next step?”; and so on. Thisapproach has been successfully implemented locallywithin Schlumberger. We now plan to define addi-tional integration governance in order to support thisapproach across the overall IT landscape.

Olivier Brousseau is Integration Manager in charge of the SOA, mas-ter data, EAI, and BPM initiatives within the Enterprise Architecturegroup of the Oilfield Services IT division of Schlumberger, a global oil-field services company with 2006 revenues of US $19 billion. Prior tojoining Schlumberger in 2005, Mr. Brousseau worked for seven yearsat Sema, a multinational consulting and systems integration firm, asthe architect on several successive projects. He holds advanced degreesin computer science and information systems from ICAM in Nantes,France, and Ecole Supérieure d’Electricité in Paris. Mr. Brousseau canbe reached at [email protected].


By definition, business process management is a man-agement discipline. One myth about BPM is “that it isall about process improvement” [3]. Yet implementingBPM is not necessarily going to make your businessprocesses more efficient. What it will do is clearly docu-ment and diagram your key business processes, assignownership, and highlight critical paths. Once this isdone, it is up to the individual units within a processflow to determine the best and most efficient ways tointeract in order to optimize that flow, if possible. Partof the failure of BPM to more effectively take root inmany organizations might be the mistaken assumptionthat purchasing and installing a BPM tool can lead toprocess optimization. This is no more true than the ideathat installing and using Microsoft Project or Primaverawill automatically result in good project management.BPM tools can be leveraged, but only after organiza-tions have developed the maturity, skill, and disciplinenecessary to carry out a sustained BPM strategy.

In order to do this, a company must first clearly docu-ment a business process. After all, at a very basic level,BPM is about documentation. Then the company mustcarefully examine each step in that process to see how itfits into the overall process and how improvements ineach step affect the performance of the entire process.

In this article, I will discuss some of the misconceptionsthat plague BPM and how organizations can avoidbeing taken in by them. I will also relate how the orga-nization I work for, the Massachusetts Medical Society(MMS), used BPM to successfully streamline three dif-ferent process flows. From those experiences, MMS hasdistilled a methodology that will help you successfullyimplement BPM in your own organization.

ADDRESSING BPM MISCONCEPTIONS

As with any other management discipline, BPM meansdifferent things to different people. Some of theseimpressions may be more hype than reality [3]. Twocommon misconceptions of BPM are:

1. BPM is a packaged solution that end users employ toautomate processes.

2. BPM, once implemented, will (magically) create moreefficient processes.

To some, especially vendors hawking software suites,BPM represents a software solution that businessescan use to model their current process flows and findinefficiencies. However, the holy grail of BPM seemsto be the ability of the business users to modify theprocess flows by simply dragging and dropping presetcomponents into the business flows. The software thensupposedly creates and writes all of the necessaryunderlying code. In this depiction of BPM, businessusers can create automated processes with little or noprogramming help from the IT department.

This scenario, though, is generally unrealistic giventhat the most critical business processes cross multipledepartments and typically have some sort of exceptionhandling or special processing that requires manualintervention in the workflow. This type of exceptionprocessing is very difficult to automate, and even if itis automated, later manual modifications become trickyand are prone to breaking the code. Furthermore, mostvendors will not support tweaks to their generatedcode; they take the position that if the code is modified,it is now the property of the modifying company andnot subject to their warranties or support.

Drag-and-drop component-based coding may be suit-able for simple process flows that generally do not varymuch from business to business. However, creating adrag-and-drop component-based toolkit would requirethe vendor to take into account every conceivable itera-tion of a workflow that any user can create. Althoughgreat in theory, it would be very time-consuming andexpensive for a vendor to implement all these potentialworkflows in a single product. In addition, automatedcode generation tools cannot easily implement a processthat spans multiple databases, departments, and, possi-bly, platforms.

The second misconception is that implementing BPMeither as a discipline or a software tool will makeprocesses more efficient [3]. In actuality, BPM is thescience and the art of documenting and outlining aprocess workflow — period. It is a science given that


BPM: Defining the Basics for Successby Mark Fung-A-Fat

MAY I SEE YOUR DOCUMENTATION?


there are certain steps and techniques that can be usedto identify and effectively document and communicatebusiness processes. It is an art because a certain amountof creativity and innate talent are also needed to accom-plish these tasks. The improvement of the workflow orprocess depends on a number of factors, chief amongthem the ability of the business units to collaborate onimproving the steps within the process and a thoroughunderstanding of how their step affects the overallchain. Such collaboration is not easily accomplished.BPM, if practiced as a corporate discipline, can be usedas a systematic approach to improving an organiza-tion’s business processes,1 but this requires that all unitsin the process chain agree to implement the necessarychanges to improve the process.

As I stated above, BPM is about documentation. Inorder to improve your processes, you must first under-stand what those processes are, what business unitsthey affect, and what value they add to your supplychain. Only when the process has been thoroughlydocumented and diagrammed can you begin to identifywhere improvements can be made. The documentation,whether it is a visual diagram or text document, canthen be further leveraged to give the different businessunits a layout of the entire process and show how theircontribution affects the overall workflow. This commonunderstanding of the entire workflow on both a microand macro level lays the necessary groundwork forprocess optimization. At this point, BPM may be usedto examine and possibly optimize the process. The keyis the creation of the document that identifies theprocess flow, not simply using the BPM tool.

OWNING THE PROCESS: THREE CASE EXAMPLES AT MMS

Despite the misconceptions, there are certainly real andvaluable reasons for implementing a BPM strategy.Before we address the benefits, though, we must con-sider how a company takes a BPM initiative and movesit from an individual project to a departmental and thena corporate platform where it can be used to improveand monitor processes on a much larger scale.

The good news is that this can be done. Indeed it isbeing done very successfully in the area of projectmanagement. Several years ago, the project manager(PM) function was focused on individual projects, bothsimple and complex. Today the PM function has becomeso critical that some companies have included a proj-ect management office (PMO) in their organizational

structure. In many ways, the goals or strategy of a corpo-rate PMO are similar to the goals of a corporate BPMstrategy: implement a set of standards, practices, andresources to effectively coordinate tasks that achievebusiness success. With projects, the success criterion isthe completion of a project — on time and on budget —that delivers key business or competitive functionality(e.g., a financial application, a Web site, a software prod-uct). With BPM, it is the successful implementation ormodification of a process to provide value to a customeror entity; that is, delivery of goods or services in aneffective and efficient manner.

An organization’s business processes are the lifebloodof its business. Competitors can often replicate a com-pany’s technology, its products, and even its lookand feel, but they cannot easily replicate its businessprocess. As supply chain expert Richard Douglassnotes, “Processes are much less visible to competitorsand therefore less subject to being easily copied” [1].

Given this background, who should initiate and/or con-trol the BPM strategy of a corporation? The answer is“anyone” — as long as he is qualified and it is his job.This individual may belong to a special BPM office, beembedded into a business unit, or even be part of theIT group. This person is qualified as long as his mainfunction is to understand, maintain, coordinate, andimplement changes to a business process and he hasthe authority and backing to do so. Having a dedicatedresource whose primary job is to understand andmonitor a process is vital to ensuring an organization’ssuccess.

E-Commerce Business Flows

At MMS, we have implemented such an approach inseveral areas with great success. In one area of ouronline business, we have identified a single person, themanager of online marketing and e-business, who isresponsible for documenting and maintaining our onlinee-commerce business flows; that is, how customers inter-act with our Web sites to purchase or pay for productsand services (see Figure 1). Any changes to any of thefive e-commerce workflows are submitted to this man-ager for her evaluation and approval. She does not makedecisions alone or in a vacuum. Rather, she is the leadmember of a team that is responsible for discussing andauthorizing the changes requested. Her role is to identifythe impact of changes on the existing workflows beforedeciding whether or not to approve the requests. Inaddition, her team determines the best time to launch

1See http://searchcio.techtarget.com/sDefinition/0,,sid19_gci1088464,00.html.



the modification(s) and communicates this message outto the rest of the company.

This manager is not part of the IT group; rather sheresides in the marketing group but works closely withIT, marketing, finance, and others to evaluate our onlinee-commerce flows and their effectiveness. In this case,the process flow is maintained and controlled by a userin the business unit. If requests are made to change oradd to this workflow, she is responsible for coordinat-ing with the appropriate departments and conveyingher knowledge of the workflow in order to evaluate,recommend, and implement the workflow change.

Customer File Transmissions

In another MMS workflow, one of the database admin-istrators in the IT group is responsible for the processthat collects customer information and sends it to athird-party vendor that hosts MMS’s content Web siteand controls access to that site (see Figure 2). Theprocess is an automated series of steps that, on a nightlybasis, collects a list of new customers who should haveaccess to our online content in addition to any changesto existing customer records (e-mail changes, addresschanges, billing status changes, etc.). This customer fileis electronically sent to the vendor, where the accesscontrol and customer profile systems are updated withthe information. In addition, part of the process alsosends out to selling agents a list of the customers whopurchased access to our content through that agency.

In this case, it is the IT department, or a user in the ITdepartment — not the business unit — that understands

and owns the process workflow. If requests are madeto add to or change the existing workflow, the IT staffmember is responsible for coordinating with the appro-priate IT staffers and other business unit members onthe scope and impact of the change before implement-ing it in production.

The overall benefit is that there is one person in the ITgroup who is familiar with and controls the data syn-chronization process. The process is now automatedand runs without incident 95% of the time. Previouslywe had several programmers all uploading data atvarious times, and as a result our data was frequentlyout of date, conflicting, or out of sync. The automateddataflow also serves as a visual document of what ishappening, thereby eliminating the need for extraneousdocumentation, which typically becomes outdated afew days or weeks after it is written. The workflowis modeled using SQL Server’s Data TransformationServices (DTS) tools and SQL Server IntegrationServices (SSIS) tools. These modules allow the ITgroup to create workflows and code similar to thosegenerated by BPM modeling tools by vendors such asIBM, TIBCO, Telelogic, EMC, and Microsoft.

The Time-Off Request Process

A third and final example of where MMS has imple-mented a BPM strategy is in our time-off requestprocess. Initially, when an employee requested timeoff, he would go to his department head and request atime-off sheet or form. The employee would then fillout the form in triplicate and have his manager sign

Send Mea Bill

Register

SelectProducts

Payment Method

Pay Bill

ChargeCard

SendConfirmation

Sign in to

Web Site

Figure 1 — The MMS Web e-commerce flow (simplified).


off on the requested time away. Once the managerapproved the time-off request, she kept a copy of theform, the employee took a copy — and no one was surewhere the third copy went!

Needless to say, this process caused a lot of confusion,and managers were never really sure what their avail-able resource pool looked like before they approvedtime-off requests. In addition, papers were often lostor misplaced, and in the end most people did not evenbother using the forms — most time-off requestsbecame verbal agreements between managers andemployees. This quickly became a problem when man-agers could not remember whether or not they hadapproved time off once an employee was out of theoffice on vacation or on a personal leave of absence.

The solution was to implement an automated processusing tools that were already in place at MMS (acombination of components provided by MicrosoftSharePoint 2003, Lawson ERP, and Microsoft’sInfoPath). The process had to accomplish three objec-tives: it had to be simple, it had to have a workflowcomponent, and it had to allow managers to seeresource availability.

The result was an online form that not only gaveemployees an electronic way of requesting time off, butalso showed them how much vacation/leave time theyhad left. Managers could process time-off requests elec-tronically, as well as view resource availability for theirentire department before approving new requests (seeFigure 3). This automated process eliminated the paperforms, which had been used in a haphazard fashion, andallowed everyone to process time-off requests in a uni-form way. A single developer in the IT group modeled,created, and now owns this process. Changes to thetime-off request process are reviewed, approved, andcoded by a group that includes managers and HR, butalways under the guidance of this process administrator.

WHAT ARE THE BENEFITS OF BPM SUCCESS?

You cannot manage what you do not measure, and youcannot change what you do not manage. Alternatively,you cannot control what you do not manage. At theheart of implementing a BPM strategy is the desireto measure, control, and possibly change a businessprocess in order to create operational efficiency or toimprove competitive advantage. A BPM strategy is veryclosely tied to continuous quality improvement andtotal quality management (TQM) efforts, as shown in

Figure 4.2 Process improvement is a key component stepof any TQM model. Even methodologies such as statisti-cal process control (SPC) — which follows a Plan, Do,Study, and Act workflow — utilize the initial stages ofBPM. The first step is to “Collect data and establish abaseline — what is the current process doing now?” [4].

WebDatabase

CustomerDatabase

Get User WebProfile

Get UserDemographics

New UsersChanges to

User Records

Format File forTransmission

WebHoster

MMSSeller Agents

Agent Ordersand Changes

Figure 2 — The MMS process for file transmissions.

CurrentProjects

TimeApproved

FutureProjects

Time

Remaining

Time-OffRequest

ManagerApproval

Resource

Calendar

Figure 3 — The MMS time-off request process.

2See www.edrawsoft.com/TQM-Diagrams.php.



For companies contemplating moving toward a service-oriented architecture (SOA), BPM is a critical first stepregardless of whether the SOA methodology will beinitiated at the corporate level or the project level. Oneof the core concepts of a SOA implementation is theautomation of specific business processes into softwareunits. These units can then be flexibly and quickly com-bined to create larger, more complex integrated sys-tems. For example, the order process can be modeledas a Web service that takes the customer information,the product information, and the payment informationand processes the order. There can be a payment servicethat takes a transaction dollar amount and a credit cardand initiates a payment. The key to identifying thesebusiness processes that will be the foundation servicesof your corporate or project-based SOA is to accuratelymodel and document them. This very action is thebeginning of the implementation of a BPM strategy.In fact, according to Lombardi Software President andCEO Rod Favaron, “BPM drives business-orientedrequirements down to the SOA layer” [2].

The essence of BPM is the creation and the implemen-tation of a culture of ownership and collaboration.The goal is to deliberately and carefully identify keyprocesses that are critical to your organization anddocument and understand the steps involved. Once thisfirst task is accomplished (and it is by no means simpleor trivial), your organization will then have a centralartifact that can be used to foster interdepartmental col-laboration and generate ideas for improving the process.

GETTING STARTED

Now that we have covered the core aspects of BPM,the misconceptions, and the benefits, we will turn ourattention to how you can initiate a BPM strategy. Thissection outlines four steps for carrying out a BPMimplementation. Although this methodology is simplein concept, at MMS we have used it successfully tocatalog and monitor some of our key processes.

1. Clearly Document the Steps in the Process

One of the chief recommendations is to start with asmall process — it can be a key business process or asimple departmental workflow. Remember, the firstgoal of a BPM strategy is to expose and clearly docu-ment the steps in the process so that some overall metriccan serve as a baseline for improvements or modifica-tions. For example, some possible metrics might be timeto complete the process from end to end, number ofmanual steps within a process, or monthly failures —any or all of which you might aim to reduce by x% inthe first six months of automation. While not every stepin the process may need to be, or can be, automated, itis beneficial to select a process that can be totally auto-mated or at least 60%-70% automated. The MMS time-off request is a good example of this. Trying to managea totally manual process, although not impossible, willprove challenging. In such cases, it is usually better han-dled through personnel management or by managingthe team that is responsible for the individual steps inthe process.

TQM Model

ProcessImprovement

ProcessManagement

PlanningProcess

TotalParticipation

CustomerFocus

Figure 4 — TQM diagram. (Source: EDrawSoft.)


2. Identify the Owner — and Tracker — of the Process

The next step is to select and identify an individual orgroup that will be responsible for the ownership andtracking of the process. Once the process flow has beendocumented, the process owner can then assemble keymembers of all business units that are affected by theprocess to review the flow. It is critical at this point thatthe documentation be validated. Everyone must agreethat the business process actually functions as outlined.Failure to do so may result in exception processing thatis still handled outside of the documented flow, whichcan make performance tracking and improvements dif-ficult if not impossible.

3. Communicate the Purpose of the Process

The third step is to communicate what the businessprocess is supposed to accomplish, review the steps inthe process, and create a series of base metrics. These willbe used as a baseline to measure improvements in theprocess as changes are made. Some of the metrics mightinclude quality of service as measured by satisfactionsurveys, data quality, time to implement a product pro-motion, orders taken over a period of time, and so on.

4. Identify and Implement Changes that Will Improvethe Efficiency of the Process

The fourth and final step is to identify any changes tothe process that might improve efficiencies and sched-ule a time frame for implementing them and measuringtheir effects. Many companies are implementing BPMstrategies by starting with their enterprise resourceplanning (ERP) systems. Many of these systems, such asthose from Oracle, JD Edwards, PeopleSoft, or Lawson,have modules that allow for the creation of businessworkflows that can incorporate steps across depart-ments. These modules can serve as a basis for creating aculture that is receptive to the basic principles of BPM— teamwork, collaboration, process documentation,and review — before the organization invests in moreexpensive BPM software that will potentially span het-erogeneous systems.

FROM FRUSTRATION TO FRUITION

The business community continues to be frustrated thatBPM tools so far have not been able to deliver on thepromise of allowing business users to create, automate,and track business processes without further IT pro-gramming. IT groups are using BPM tools mainly asdiagramming tools and do not leverage the power ofthese modelers to automate and measure the processes

that they model. This is primarily because of the lackof training and the investment (in time and money)required to implement the additional components thatare necessary to fully realize the benefits of these tools.IBM, for example, has an array of supporting softwarethat allows for the creation of business processes, collec-tion of process execution metrics, modeling of what-ifscenarios, and a variety of other features. However, thetotal suite of required products is not cheap, requirestraining, and, once adopted, requires an IT commitmentto create and fully support an IBM-based infrastructure.

In the meantime, companies can take advantage of thelessons learned from project management to createmethodologies aimed at identifying and managing keybusiness processes. They can then work aggressivelywith vendors and IT to automate, where possible, largeportions of these processes. It should be noted, how-ever, that there are some areas that may not be easily“improved” for political or even quality reasons. Aprime example is customer phone support. Many com-panies have automated their customer phone supportservices, replacing human operators with automatedvoice response systems. While these may be seen asmodels of efficiency, frustrated customers often attemptto bypass these systems by pressing the universal “0”button in an effort to speak to a real person.

Although the BPM industry has apparently failed todeliver on its promise of revolutionary products andmethods to model and improve business processes,there are still key lessons that companies can learn fromimplementing a BPM strategy. There are tools availablethat can be leveraged to automate, manage, and improvekey systems and processes. The trick is to selectivelyidentify and manage key processes rather than imple-ment BPM as a corporate strategy in a nebulous way.

The most common modeling tool used at MMS, andprobably other companies, is Microsoft Visio. Part ofthe problem is that this tool does not integrate into asystem that can be used to capture statistics regardingprocess execution times. Another common modelingand diagramming tool used by the IT staff at MMS isMicrosoft’s DTS and SSIS modules, which are part ofthe Microsoft SQL Server suite (2000 and 2005). TheIT database group uses these tools to design and runprocesses that move data between our back-end systemsand external vendors. Over the next few months, MMSwill be investing in an enterprise scheduling softwarepackage that can take a series of currently scheduledtasks and fit them into an automated workflow. Thesoftware package gives us the ability to visually createthese flows and will also track runtime statistics at the



task and process levels. One critical point to note is thatprior to doing this, MMS had to work on the basics ofdefining its BPM strategy: identifying processes to con-trol, documenting the process, and assigning an owner.Once we had documented and automated key businessand IT processes, we were able to monitor their perfor-mance over time and then determine what additionalfunctionality we needed in order to further optimize notonly our process flows, but also the use of our internalresources.

MMS has implemented BPM strategies around severalkey customer-facing and internal-facing processes andhas seen marked improvements in both market compet-itiveness and operational and human resource costs. Inthe future, we are seeking to leverage our knowledgeof BPM to investigate more sophisticated tools andsoftware packages that can be used to monitor theseprocesses and allow us to make better use of ourresources. The main point is not to purchase the latestBPM software but to model and understand our processfirst, then choose the appropriate tools that will give usthe most benefit. Sometimes these tools are not BPMtools but simple software applications that your com-pany may already own, such as Visio, PowerPoint,Word, or even Excel. Anything that can be used to cre-ate a graphical model of a process flow can work. Thekey is to create a culture where process modeling andmanagement are valued as critical business skills. Oncethis foundation is established, companies can start to

investigate tools that will enable them to more effec-tively coordinate and execute their work. The toolsthemselves will not solve the problems of inefficientprocess flows unless the users understand the processand are willing to collaborate on changing in order tocreate a more efficient system.

REFERENCES

1. Douglass, Richard. “BPM: Process for the Alert Enterprise.”BPM.com, 21 March 2006 (www.bpm.com/FeatureRO.asp?Featureid=199).

2. Favaron, Rod. “A Business-Oriented Architecture.” BPM.com,31 August 2006 (www.bpm.com/FeatureRO.asp?Featureid=217).

3. Spurway, Kevin. “The State of BPM: Perspectives of anIndustry Insider.” BPM.com, 2 August 2007 (www.bpm.com/FeatureRO.asp?FeatureId=237).

4. Statit Quality Control First Aid Kit: Introduction to ContinuousQuality Improvement Techniques for Healthcare ProcessImprovement. Statit Software, Inc., 2007 (www.statit.com/services/CQIOverview.pdf).

Mark Fung-A-Fat has been working in the IT industry since 1991and is currently the Director of Software Development for theMassachusetts Medical Society (MMS) and the New EnglandJournal of Medicine. He holds a BSc in computer science andmathematics and an MSc in computer science. Mr. Fung-A-Fat canbe reached at [email protected].

As the BPM marketplace continues its rapid evolution,there is an increasing array of technology offeringsavailable for modeling and enacting business processes.Yet despite the advances that have been made in theprocess technology area, it is more difficult than everfor organizations to select an appropriate tool on whichto base their business processes. These difficulties stemfrom two major causes: (1) the increasing diversity ofofferings that fall under the BPM technology umbrella,and (2) the complexity associated with reconciling theneeds of the organization and the capabilities of avail-able products.

As illustrated in Figure 1, the potential range of tech-nologies on which a BPM solution might be based isincredibly diverse, and the suitability of any given toolis influenced markedly by both the degree of flexibilitythat the to-be-enacted process demonstrates and thenature of the resources (people and/or application) thatneed to be coordinated.

Moreover, the capabilities of individual tools differ sig-nificantly, and one of the main difficulties organizations

experience when evaluating different offerings is find-ing a suitable basis for comparison. The fact that eachtool is usually based on a distinct modeling and enact-ment formalism, and that vendors often choose to usevarying terminology for the same concepts, only servesto further complicate the issue.

What is required is a means of benchmarking the capa-bilities of a BPM solution in a manner that is indepen-dent of specific technological and implementationconsiderations. This would allow the capabilities ofindividual BPM tools to be directly compared and pro-vide a basis for assessing the ability of different prod-ucts to meet your organization’s specific BPM needs.In the following pages, we present a framework fordoing just that.

THE SCOPE OF A BUSINESS PROCESS

Central to establishing a set of benchmarks for BPMsolutions is the issue of setting the scope for thesebenchmarks. It seems self-evident that the benchmarks


All That Glitters Is Not Gold: Selecting the Right Tool for Your BPM Needsby Nick Russell, Wil M.P. van der Aalst, and Arthur H.M. ter Hofstede

PROVE IT WITH PATTERNS

ProjectManagement

Ad HocFramed

Unframed

LooselyFramed

TightlyFramed

WorkflowTrackingSystems

P2P P2A A2A

A2A and B2BIntegrationProcesses/

ServiceComposition

CaseHandling/Flexible

Workflow

Ad HocWorkflow

ScientificWorkflow

Process-UnawareApplication Integration

Groupware

Process-AwareCollaboration Tools

Adher

ence

to

Def

ined

Pro

cess

Focus of BPM Solution (P = Person; A = Application)

Figure 1 — The wide range of BPM-relevant technologies.



should be framed with reference to the notion of abusiness process; however, there is a surprisingly widerange of views as to what constitute the relevant com-ponents of a business process, both for modeling andenactment purposes. This diversity is reflected in thebroad range of models that underpin distinct BPMofferings.

In order to circumvent these considerations, we take abroad view of a business process and consider it to becomposed of three distinct (but interrelated) perspectives:

1. The control-flow perspective, which describes thestructure of a business process in terms of its con-stituent activities; the manner in which the process isimplemented (considering both activities that have adirect implementation and also those that are definedin terms of a subprocess); and the interconnectionsbetween them in terms of the overall flow of control

2. The data perspective, which describes how data ele-ments are defined and utilized during the executionof a business process

3. The resource perspective, which describes the overallorganizational context in which a business processfunctions and the manner in which individual activi-ties can be assigned to human resources for subse-quent execution

By setting a comprehensive basis for characterizingbusiness processes, we allow a wide range of factorsto be considered when establishing benchmarks. Theprocess of determining individual benchmarks is basedon the identification of components within businessprocesses that have generic applicability and are recur-rent in form. We call these components “patterns.”

RECURRENT COMPONENTS (I.E., PATTERNS)

In an effort to gain a better understanding of the funda-mental concepts underpinning business processes, theWorkflow Patterns Initiative was conceived in the late

1990s with the goal of identifying the core architecturalconstructs inherent in process technology. Our originalobjective was to delineate the fundamental require-ments that arise during business process modeling on a recurring basis and describe them in a solutions-oriented way.

We and our fellow researchers took a patterns-basedapproach to describing these requirements, as it offeredboth a language-independent and technology-indepen-dent means of expressing their core characteristics in aform that was sufficiently generic to allow for its appli-cation to a wide variety of tools. The use of patterns toidentify recurrent concepts in a given domain and pro-pose general solutions to them was first advocated byChristopher Alexander as a means of describing generalarchitectural principles for building design [1]. It wassubsequently introduced with great success into the ITdomain by the Gang of Four, who described a series ofsoftware design patterns for object-oriented systems [2].

In line with these approaches, which are based on abroad survey of existing problems and practices withina particular field, we (and other researchers affiliatedwith the Workflow Patterns Initiative) identified a basicselection of 20 control-flow patterns through a compre-hensive evaluation of workflow systems and processmodeling formalisms [6]. These patterns describe aseries of common requirements that arise when model-ing control-flow structures within a business process.The imperative approach employed in their descriptionensures that their intent and function are clearly pre-sented without mandating a specific implementationapproach. An overriding objective of the patterns wasto describe control-flow characteristics that are usefuland therefore need to be supported in a given offering.Each pattern is presented using a standard format,which includes the content shown in Table 1.

After almost a decade of research, we have identifiedmore than 120 patterns in the control-flow [4], data [3],and resource [5] perspectives. All of these are relevant

Description A summary of its functionality

Examples Illustrative examples of its usage

Motivation The rationale for the use of the pattern

Overview An explanation of its operation, including a detailed operational definition where necessary

Context Other conditions that must hold in order for the pattern to be used in a process context

Implementation How the pattern is typically realized in practice

Issues Problems potentially encountered when using the pattern

Solutions How these problems can be overcome

Evaluation criteria The conditions that an offering must satisfy in order to be considered to support the pattern

Table 1 — Standard Pattern Contents


for the purpose of benchmarking the capabilities ofBPM offerings. In the following sections, we outline thepatterns in each of these perspectives.

Control-Flow Patterns

Control-flow patterns describe structural characteristicsof a business process and the manner in which thethread of control flows through the process model.There are 43 distinct control-flow patterns, which aredivided into nine distinct groups on the basis of theirarea of focus:

1. Fundamental control-flow patterns capture elemen-tary aspects of control-flow.

2. Branching patterns describe branching scenariosin processes where the thread of control in a givenincoming branch is split into one or more subsequentbranches on the basis of criteria specified in theprocess model.

3. Synchronization patterns describe synchronizationscenarios in processes where the thread of control inone or more incoming branches is synchronized (andpossibly merged) before being passed on to a subse-quent branch on the basis of criteria specified in theprocess model.

4. Multiple instance patterns delineate situations wherethere are multiple threads of execution in a processthat relate to the same case/activity.

5. Repetition patterns describe various ways in whichiteration may be achieved in a process.

6. State-based patterns reflect situations that are mosteasily modeled in process languages with an explicitnotion of state.

7. Trigger patterns define situations where externalevents are used to synchronize the commencement ofan activity.

8. Cancellation and completion patterns categorize thevarious cancellation and forced-completion scenariosthat may be relevant to activities within a process.

9. Termination patterns address the issue of when theexecution of a process is considered to be finished.

In order to illustrate the operation of the control-flowpatterns, it is worthwhile to consider an example. TheDeferred choice pattern operates in the control-flowperspective. It provides a decision point in a givenbranch of a process where one of two (or more) alter-nate branches is selected as a consequence of commenc-ing the first activity in the chosen branch rather than onthe basis of some preceding choice. The actual decision

of which branch to choose is made at the last possiblemoment (i.e., when the chosen branch is actuallystarted). It may take into account a variety of factors(not just control-flow considerations, but also datavalues, resource availability, etc.) and results in anexplicit choice being made between the various out-going branches.

As an example, Figure 2 shows a fragment of the “com-mute to work” process. After the commuter leaves thehouse, he faces a choice of walking or taking the busto work. Only one of these options can be chosen, andtypically the commuter also takes additional (i.e., envi-ronmental) information into account when making thedecision, such as whether it is raining and how muchtime he has for the journey. Hence the deferred choiceexists between the “walk to work” and “take the bus”activities, and the deferred choice node marks the pointat which the moment of choice exists. Note that unlikethe “normal choice” present in all languages, thedeferred choice is not determined based on data or someother decision activity; the choice is made by doing.

Data Patterns

From a data perspective, there are a series of character-istics that occur repeatedly when modeling businessprocesses. These can be divided into four distinct groups:

1. Data visibility patterns define the scope (i.e., theextent of the process) in which a data element isdefined and can be used.

2. Data interaction patterns focus on the manner inwhich data is communicated between active com-ponents (e.g., activities, subprocesses, and parentactivities) within a process and also between thosecomponents and the operating environment in whichthe process is situated.

3. Data transfer patterns describe various means bywhich the actual transfer of data elements occursbetween components in a process.

Leave House DeferredChoice

Walk to Work

Take the Bus

Figure 2 — Example of the Deferred choice pattern.



4. Data-based routing patterns characterize the mannerin which data elements can influence the operation ofother aspects of the process, particularly the control-flow perspective.

Data transformation – input is a data transfer patternthat provides a means of changing the format or valueof an incoming data parameter to an activity before (orat the time that) the activity commences. An exampleof this is illustrated in Figure 3 with the “value portfo-lio” activity receiving price feed data from the stockexchange at commencement but only requiringprice data for the portfolio it is valuing. Hence the get-stock-prices() function is called to extractthe stock prices for items in the portfolio from all ofthose that were provided.

This brings us to the third group of patterns, whichdescribe the resource perspective and provide a meansof defining how a process (and its constituent activities)should be executed in the organizational context inwhich it is situated.

Resource Patterns

There are 43 resource patterns, which are divided intoseven distinct groups as follows:

1. Creation patterns correspond to design-time workallocation directives for individual activities.

2. Push patterns are those in which the system proac-tively distributes activities to human resources.

3. Pull patterns describe situations where resourcesproactively identify and commit to executing specificactivities.

4. Detour patterns involve the rerouting of activitiesthat have already been distributed to one or moreresources, either at the instigation of the resource(s)or the system.

5. Auto-start patterns describe the automated com-mencement of individual activities based on variouscriteria.

6. Visibility patterns describe the observability of activ-ities (and their current status details) to resourcesassociated with a process.

7. Multiple resource patterns correspond to work allo-cations involving multiple participants or resources.

The Delegation pattern operates in the resource perspec-tive. Figure 4 illustrates the normal sequence of statesthrough which an activity passes from the time that it iscreated through to the point at which it is completed bya resource. Usually this involves allocation of the activ-ity to a specific resource, who will undertake it at a latertime. Delegation provides a resource with a means ofreallocating activities that she is unable to complete toanother resource for execution.

There are 126 distinct patterns corresponding to thethree perspectives described above. Additional patternshave also been defined for other aspects of processes,such as exception handling. The conceptual nature ofthese patterns means that they provide an excellentbasis for describing the capabilities of a BPM solutionfrom a conceptual standpoint. In the next section, wedescribe the manner in which this is done.

ValuePortfolio

ReviewPortfolio

Risk

get-stock-prices()

PriceFeed

Figure 3 — Example of the Data transformation – input pattern.

CreateCreated

Offer

Offer

Offered toa Single

Resource

Allocate

Allocate

Allocate

Offered toMultiple

Resources

Allocated

Start

Start

Start

Delegate

Suspend

Suspended

Started

Failed

Resume

Complete

Completed

Fail

Figure 4 — Illustration of the operation of the Delegation pattern in the context of the overall activity lifecycle.


BENCHMARKING TOOL CAPABILITIES

Whilst traditional tool evaluations provide usefulinsights into product functionality, they often do so at arelatively high level and consequently do not provide ameans of evaluating specific capabilities of individualofferings. In contrast, using patterns for benchmarkingtool capabilities provides detailed insights into specificabilities and shortcomings of individual tools.

By definition, patterns identify meaningful constructsthat exist in a given problem domain. Therefore, it is cru-cial that the identification of patterns be experientiallybased. Typically this occurs through a survey of theiractual occurrence in practice. Our identification of theworkflow patterns was no different in this regard, andwe based their identification on a comprehensive evalua-tion of workflow and case-handling systems, businessprocess modeling and execution languages, and Webservices composition standards. The process we adoptedfor identifying and validating individual patterns isillustrated in Figure 5. A crucial part of this activity isthe definition of specific pattern assessment criteria thatallow the degree of support for individual patterns ina given offering to be evaluated on an objective basis.Subsequent review of the evaluation results with rele-vant vendors and domain experts is also vital in orderto ensure the correctness and validity of these results.

As a consequence of their technological neutrality, thepatterns have proven to be extremely useful for provid-ing a comprehensive assessment of the capabilities ofindividual products and standards. They have beenfound to be especially useful for comparing the capa-bilities of individual offerings in order to identifytheir strengths and weaknesses, and more generallythey provide an effective set of evaluation criteriaorganizations can use when selecting a BPM tool. TheWorkflow Patterns Initiative has undertaken a multi-tude of patterns-based assessments that have revealedproblematic aspects of these offerings and providedsuggestions for improvement.1

Tables 2-4 provide a brief summary of the manypatterns-based evaluations of systems and standards

we have conducted over the past seven years. As anillustration of the broad applicability of the patternsfor benchmarking purposes, we present the evaluationresults for a variety of distinct offerings, including:

Two workflow systems: Staffware Process Suite 10and WebSphere “classic” 3.4

A case-handling system: FLOWer 3.5.1

A business process modeling formalism: BPMN 1.0

A business process execution language: WS-BPEL 2.0

A BPEL execution engine: Oracle BPEL v10.1.2

The results indicate the capabilities of each tool. In eachcase, we use a three-point evaluation scale, indicatingcomplete (+), partial (+/–), or lack of (–) support for thepattern.

Table 2 summarizes the support for state-based control-flow patterns; that is, just five of the 43 control-flow pat-terns. The Deferred choice pattern, which is one of these,is discussed above. The other patterns are as follows:

The Milestone pattern describes a situation where theexecution of an activity depends on the process ofwhich it is part being in a nominated state.

The Interleaved routing pattern describes situationswhere a set of activities can be executed in any orderon a sequential basis.

The Interleaved parallel routing pattern extends this tocover situations where there is an implied partialorder in which the activities must be executed.

The Critical section pattern describes the situationwhere two or more subsections of a process are iden-tified that cannot execute concurrently.

Interestingly, of the offerings examined, the broadestsupport for this range of patterns is demonstrated by acase-handling system, FLOWer.

Table 3 illustrates support for data routing patterns — one of the groups of data patterns — amongst theselected tools. Although the naming of these patternsmakes their intent relatively self-evident in most cases,

1Further details on the workflow patterns, including detailed definitions, product evaluations, animations, vendor feedback, and anassessment of their overall impact, can be found at www.workflowpatterns.com.

Select Toolsto Be

Assessed

IdentifyPatterns

Set EvaluationCriteria

EvaluatePatternsSupport

Review Findingswith Vendors

Figure 5 — Pattern identification and validation.



Deferred choice – – + + + +

Milestone – – +/– – – –

Interleaved routing – – +/– +/– + –

Interleaved parallel – – +/– – +/– –

routing

Critical section – – +/– – + +

Staffware Oracle BPELWebSphere FLOWer BPMN WS-BPEL

Table 2 — Support for State-Based Patterns

Task precondition — data existence

+ – + + – –

Task precondition — data value

+ – + – + +

Task postcondition — data existence

+/– + + + – –

Task postcondition — data value

+/– + + – – –

Event-based task trigger

+ +/– + + + +

Data-based task trigger –

– + + – –

Data-based routing +/– + +/– + + +


Table 3 — Support for Data Routing Patterns

Delegation + + – – – +

Escalation + + – – – +

Deallocation – – – – – +

Stateful reallocation +/– + – – – +

Stateless reallocation – – – – – –

Suspension/resumption

+/– +/– – – – +

Skip – + + – – +

Redo – – + – – –

Pre-do – – + – – –


Table 4 — Support for Detour Patterns


it is worth describing the last three of them to avoidambiguity:

The Event-based task trigger pattern describes an activ-ity whose execution is contingent on the receipt of atrigger containing a specific data element from theoperating environment.

The Data-based task trigger pattern is similar, exceptthat the activity is triggered when an internal datacondition is satisfied.

The Data-based routing pattern describes a situationwhere the routing of control-flow is dependent onconditions specified as part of the process model.

Most of these patterns enjoy relatively broad supportamongst the offerings examined, although there aresome notable variations.

Table 4 shows the degree of support for detour patterns,one of the groups of resource patterns. The Delegationpattern discussed earlier is a member of this group. Itis notable that BPMN and WS-BPEL 2.0 do not pro-vide any support for resource-related capabilities.Interestingly, Oracle BPEL does offer a range of capa-bilities in this area that are not specified as part of theBPEL standard.

Worthy of mention at this point is the YAWL system,an open source initiative inspired by the identified pat-terns, which further investigates their implementationand semantics.2

MEETING YOUR NEEDS

We hope the preceding sections have demonstratedhow the workflow patterns we’ve identified can be usedto describe the capabilities of individual BPM solutionswith a degree of precision that is not possible with otherevaluation frameworks. This raises the question of howyou can harness the benefits of this research in order toselect the most appropriate BPM tool for your needs. Tobest match the capabilities of available offerings to yourrequirements, you need to work through the followingactivities.

Understand Your Business Imperatives

The first step in selecting a BPM solution is assessingwhat you want the tool for. Although many offerings arerelatively flexible and are capable of meeting a broad

range of requirements, it is possible that there is nosingle tool that will meet with all of your needs. Con-versely, many of the high-profile solutions offer anextremely broad range of capabilities at a commensurateprice, and it’s possible that your needs might be ade-quately met by a less expansive (and, likely, less expen-sive) offering. To understand your business imperatives,the sort of questions you should be asking are:

Which business processes will this tool be used toautomate?

What is it coordinating — staff members, softwareexecution, message distribution, external services?

Who are the stakeholders in this process, and whatsupport do they require in managing it?

Where do the potential costs/benefits lie?

Identify Mandatory, Important, and Desired Capabilities

With a better understanding of the overall businessimperative for acquiring a BPM tool, it becomes possi-ble to think at an operational level about the functionsthat it will be required to support. The various patternscatalogs — control-flow, data, and resource — providea useful checklist for identifying specific functionalrequirements. From a pragmatic standpoint, it is worth-while to divide these requirements into mandatory,important, and desirable categories, so that there is ascalar across the overall set of functional requirementsthat ranks their relative degree of importance.

Establish Satisfaction Criteria

In order to ensure that the tool selection process isobjective, it is important to define satisfaction criteriabefore undertaking the tool evaluation. The overall setof selection criteria will probably include a wide rangeof considerations, but for the purposes of this discus-sion, we will confine ourselves to those related to theworkflow patterns. Possible approaches to specifyingsatisfaction criteria include scoring approaches based onquantitative pattern support, nomination of mandatorypatterns, and comparative rankings.

An important part of this activity is establishing theminimum satisfaction criteria. Where no offerings areidentified that meet these criteria, there is then theopportunity to consciously review them rather thanmerely procuring the least unacceptable tool. It’s allvery well to set tight satisfaction criteria, but if they are

2Further details are available at www.yawl-system.com.



so tight that none of the commercially available prod-ucts meet them, then you have only two choices: (1)abandon the procurement initiative, or (2) recognizethat the requirements are too tight and objectivelyconsider which ones you’re prepared to relax.

Benchmark Potential Solutions

In many cases, comprehensive patterns reviews arealready available for specific BPM offerings.3 Where thisis not the case, you will need to undertake a patterns-based assessment of the tools in which you areinterested.4

Select the Tool

Finally, it’s D-Day! Armed with your benchmark resultsand satisfaction criteria, you’re in a position to selectyour BPM tool, knowing that the entire process hasbeen undertaken in an objective way.

REAL-WORLD SUCCESS

Several large Dutch organizations have already adopteda patterns-based approach to tool selection withextremely beneficial results. Moreover, we know fromexperience that a patterns-based approach to evaluatingBPM solutions offers insights into the operational char-acteristics of tools that are difficult to obtain in otherways. By following this approach to selecting a BPMsolution, you will know more about your BPM needsand the ability of the offerings you examine to deliveron those requirements.

REFERENCES

1. Alexander, Christopher, Sara Ishikawa, and MurraySilverstein. A Pattern Language: Towns, Buildings, Construction.Oxford University Press, 1977.

2. Gamma, Erich, Richard Helm, Ralph Johnson, and JohnVlissides. Design Patterns: Elements of Reusable Object-OrientedSoftware. Addison-Wesley Professional, 1995.

3. Russell, Nick, Arthur H.M. ter Hofstede, David Edmond, andWil M.P. van der Aalst. “Workflow Data Patterns: Identification,Representation, and Tool Support.” In Proceedings of the24th International Conference on Conceptual Modeling (ER 2005),Vol. 3716 of Lecture Notes in Computer Science, edited by LoisM.L. Delcambre, Christian Kop, Heinrich C. Mayr, JohnMylopoulos, and Oscar Pastor, Springer, 2005, pp. 353-368.

4. Russell, Nick, Arthur H.M. ter Hofstede, Wil M.P. van derAalst, and Nataliya Mulyar. Workflow Control-Flow Patterns: ARevised View, BPM Center Report BPM-06-22. BPMcenter.org,2006 (http://is.tm.tue.nl/staff/wvdaalst/BPMcenter/reports/2006/BPM-06-22.pdf).

5. Russell, Nick, Wil M.P. van der Aalst, Arthur H.M. terHofstede, and David Edmond. “Workflow Resource Patterns:Identification, Representation, and Tool Support.” In Proceedingsof the 17th Conference on Advanced Information Systems Engineering(CAiSE’05), Vol. 3520 of Lecture Notes in Computer Science,edited by Oscar Pastor and João Falcão e Cunha, Springer,2005, pp. 216-232.

6. Van der Aalst, W.M.P. , A.H.M. ter Hofstede, B.Kiepuszewski, and A.P. Barros. “Workflow Patterns.”Distributed and Parallel Databases, Vol. 14, No. 3, July 2003, pp. 5-51.

Nick Russell has 20 years’ experience in the Australian IT industry ina variety of technical and senior management roles. During this time,Mr. Russell has led a number of high-profile systems integration andproduct development initiatives for organizations in the financial andretail sectors. He recently completed his PhD studies at QueenslandUniversity of Technology in Brisbane, Australia, and is currently con-ducting research into business process management and process-awareinformation systems at the Technische Universiteit Eindhoven in theNetherlands. He is a major contributor to the Workflow PatternsInitiative and has been the driving force for several recent researchefforts in this area. Mr. Russell can be reached at [email protected].

Wil van der Aalst is a professor of information systems at theTechnische Universiteit Eindhoven in the Netherlands. His researchinterests include workflow management, process mining, Petri nets,business process management, process modeling, and process analysis.Many of his papers are highly cited, and his ideas have influencedresearchers, software developers, and standardization committeesworking on process support. Prof. van der Aalst is a founder of theWorkflow Patterns Initiative and continues to guide its research activ-ities. He is also committed to open source initiatives such as ProM andYAWL. Prof. van der Aalst can be reached at [email protected].

Arthur H.M. ter Hofstede is an associate professor in the Faculty ofInformation Technology of Queensland University of Technologyin Brisbane, Australia. He is a founder of both the Workflow PatternsInitiative and the YAWL Initiative and remains committed to bothof these research efforts. He is a steering committee member of theBPM Conference Series. A/Prof. ter Hofstede can be reached [email protected].

3See www.workflowpatterns.com/documentation/index.php for a summary of the relevant papers under “Evaluations.”

4There is a multitude of information available on the Workflow Patterns Web site (www.workflowpatterns.com) to assist withthis process.

Making decisions based on anyapplication metadata, data, orexternal events

Supporting incremental refinementof processes or subprocesses

Interfacing easily with a variety ofapplication architectures

Controlling system access, storingrecords of changes, and acceptingfree-form notes along withstructured data

You’ll also explore the inherent techni-cal issues associated with workflowsystems, the 20 control patterns thata workflow system should ideallysupport, and the five process manage-ment “stress cases” a workflow systemshould handle.

Plus, you’ll get detailed descriptions ofthe groupware and collaborative capa-bilities of a WIP; a WorkThru frame-work implementation; the mechanismsthat comprise the WIP’s lifecycle; thearchitecture of a WorkThru; and aWIP’s progression through a long-running process driven by a metadatatable of “needs.”

Learn how to improve the function-ality of your BPM approach by usingobjects instead of procedures. Orderyour copy of BPM in Peril: Objects tothe Rescue today!

Summary

Business process management (BPM)has the potential to deliver tangiblebusiness value to an organization.Unfortunately, current BPM solutionsperpetuate an approach that has keptworkflow systems — BPM’s core tech-nology — from being as successful asthey might be. Routing work processeson a track almost completely separatefrom the rest of the application createsreal implementation problems. How-ever, taking an object approach tohandling long-running processes is amore viable solution.

In the report BPM in Peril: Objects to the Rescue, author John Tibbetsdemonstrates how using an object-oriented approach to process manage-ment, specifically the WIP (work-in-progress) approach, makes it easierto build systems that can handle therange of activities required for ensuringdata integrity and workflow. You’lllearn how the WIP approach resolvescomplexity; makes for a more flexible,easy-to-understand system; andimproves application design as a whole.

Discover how a WIP can helpyou safely manage long-running processes by:

Enabling cross-dependent workflowsthrough intercommunication

Supporting threaded discussionsthat can be anchored to any fieldor aggregation of fields

CUTTER CONSORTIUM

BPM in Peril: Objects to the RescueTitle: BPM in Peril:

Objects to the Rescue

Author: John Tibbets

Published: June 2006

Pages: 22

Price: US $150

BusinessIntelligence

37 Broadway, Suite 1, Arlington, MA 02474-5552 www.cutter.comCUTTER CONSORTIUM

Go to www.cutter.com/bookstore.html



http://www.cutter.com/bookstore.html

Cutter IT Journal

About Cutter ConsortiumCutter Consortium is a truly unique IT advisory firm, comprising a group of more than100 internationally recognized experts who have come together to offer content,consulting, and training to our clients. These experts are committed to delivering top-level, critical, and objective advice. They have done, and are doing, groundbreakingwork in organizations worldwide, helping companies deal with issues in the core areasof software development and agile project management, enterprise architecture, businesstechnology trends and strategies, enterprise risk management, metrics, and sourcing.

Cutter offers a different value proposition than other IT research firms: We give youAccess to the Experts. You get practitioners’ points of view, derived from hands-onexperience with the same critical issues you are facing, not the perspective of a desk-bound analyst who can only make predictions and observations on what’s happening inthe marketplace. With Cutter Consortium, you get the best practices and lessons learnedfrom the world’s leading experts, experts who are implementing these techniques atcompanies like yours right now.

Cutter’s clients are able to tap into its expertise in a variety of formats, including contentvia online advisory services and journals, mentoring, workshops, training, and consulting.And by customizing our information products and training/consulting services, you getthe solutions you need, while staying within your budget.

Cutter Consortium’s philosophy is that there is no single right solution for all enterprises,or all departments within one enterprise, or even all projects within a department. Cutterbelieves that the complexity of the business technology issues confronting corporationstoday demands multiple detailed perspectives from which a company can view itsopportunities and risks in order to make the right strategic and tactical decisions. Thesimplistic pronouncements other analyst firms make do not take into account the uniquesituation of each organization. This is another reason to present the several sides to eachissue: to enable clients to determine the course of action that best fits their uniquesituation.

For more information, contact Cutter Consortium at +1 781 648 8700 [email protected].

The Cutter BusinessTechnology CouncilThe Cutter Business Technology Councilwas established by Cutter Consortium tohelp spot emerging trends in IT, digitaltechnology, and the marketplace. Itsmembers are IT specialists whose ideashave become important building blocks oftoday’s wide-band, digitally connected,global economy. This brain trust includes:

• Rob Austin• Ron Blitstein• Christine Davis• Tom DeMarco• Lynne Ellyn• Jim Highsmith• Tim Lister• Lou Mazzucchelli• Ken Orr• Ed Yourdon


Documents

Cutter · The value of high-quality data ... BPM proof-of-concept or a full-fledged BPM rollout is likely to stumble across certain issues that may jeop-ardize the BPM effort —