"Whereas some of the more historical BPM initiatives were focused on automation, monitoring, and optimization of business processes, the modern BPM approach stresses flexibility; that is, the ability to quickly change processes as the business changes."

BPM Is the Way to Go

BPM sets the stage for process agility. For frequently changing, high-volume process optimization, BPM is the right technology and a promising approach that will flex your IT architecture.

BPM Has a Ways to Go

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

Opening Statement

Business process management (BPM) is a concept that has been alive in the IT world for many years under the guise of various names and labels. In the client-server era of the 1990s, BPM tools were called workflow management systems. The main vendors from this era -- FileNet, Staffware, IBM -- and many others provided us with so-called workflow engines that, based on a process definition, would route work between process participants, be they human actors or computers. Back then, the Workflow Management Coalition was formed with the aim of standardizing the logical architecture and interfaces of typical workflow systems. The architecture (The Workflow Reference Model Diagram¹) has not changed one bit to this day. In fact, in most current BPM toolsets we can still identify:

• A process definition tool

• An enactment engine (process server)

• Administration and monitoring tools (these days often labeled business activity monitoring, or BAM, tools)

• A workflow client application that handles work items and invoked applications (nowadays, typically Web services)

Workflow management tools (or process management tools, as they started to be called) quickly became a standard offering of the more complex enterprise application integration (EAI) suites. As automatic management of business processes -- especially ones that did not require human intervention -- was seen as one of the cornerstones of advanced EAI solutions, we saw leading EAI vendors putting BPM engines on top of their EAI suites. One of the popular ways many EAI vendors sought to fill the void in their EAI suites was actually to acquire one of the former workflow vendors.

Today we are deeply entrenched in advanced enterprise architecture concepts that revolve around the idea of service-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 "BPM standards war" with Business Process Execution Language (BPEL) emerging as a clear winner.

Since I started working on BPM-related issues back in the mid-1990s, one thing has not changed -- the marketing hype. Business users are led to believe that they can effortlessly, without IT intervention, change business processes as they go and that they will be able to quickly assemble new business processes from predefined "building blocks" as their business changes. But the ability to change the business process "on the fly" is not the only perceived benefit of BPM. We also hear BPM suite vendors promising:

• Fast development and improved time to market, with BPM suites having the ability to generate, from a model, complex, cross-departmental applications that automate complicated process flows

• Increased process transparency, traceability, and control, which leads to better alignment of operations and strategy and decreased risk of noncompliance with standards and regulations

• Process optimization and increased process efficiency, 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 focused on automation, monitoring, and optimization of business processes, the modern BPM approach stresses flexibility; that is, the ability to quickly change processes as the business changes. Over the years we have gotten better and better at process optimization, both from the business point of view (with approaches such as Six Sigma) and from the IT point of view (with ever-improving EAI technology and techniques, which allow for more straight-through processing and faster business cycles). Today, however, the main business focus is on agility and innovation, thanks to a fast-changing business environment as well as new products, business models, and government regulations disrupting day-to-day business operations. In this environment, IT may find that -- instead of its traditional role as an enabler -- it may suddenly become a roadblock to fast business change. Interestingly enough, it is quite possible that your BPM efforts from several years ago may today form a hard-to-get-rid-of IT legacy.

In this issue of Cutter IT Journal, our authors offer their views of modern BPM and present us with a few case studies that show us what, in their opinion, can be achieved and what should be avoided. With such a long list of promised benefits, it is perhaps not surprising that many vendors are trying to ride the BPM wave and many business users and IT departments are trying to realize some of these benefits. However, when push comes to shove, a typical organization attempting a BPM proof-of-concept or a full-fledged BPM rollout is likely to stumble across certain issues that may jeopardize the BPM effort -- especially when the main expected benefit is flexibility and agility. So let us have a look at how our authors define BPM and approach BPM initiatives.

In our first article, Michael Hartges, Dirk Krafzig, Michael Kunz, Florian Mösch, Dirk Slama, and Thomas Stahl see BPM as a management discipline comprising analysis, planning, control, and optimization of business processes. They distinguish BPM from other approaches such as business rules management (BRM), workflow management, process-driven business intelligence (BI), and others, emphasizing that BPM particularly promises optimization potential for business processes if workflows can be defined explicitly, the potential for process optimization is high (as should be the case for frequent, repeatable processes), and the course of the process changes frequently. They present us with a comprehensive vision for BPM and "enterprise SOA" that includes both BPM and BRM. In the view of Hartges et al., BPM is part of a broader, SOA-based enterprise architecture, consisting of enterprise portals, a portfolio of enterprise services, operational data stores, and a data warehouse. The authors conclude with a case study of T-Mobile's BPM/SOA efforts, which provides us with a specific approach to BPM implementation.

In our next article, Cutter Senior Consultant Borys Stokalski and Marcin Strozanski offer a case study from Telekomunikacja Polska S.A., a large Polish telecommunications group, which is aiming to make its organization more agile by pursuing what Stokalski and Strozanski label "adaptive process automation." The authors see BPM tools as specialized middleware and management tools that can help an organization to quickly assemble services implemented in its enterprise services portfolio into an automated process and to orchestrate its execution. Such tools pave the way to the prototyping of business processes in a way similar to application prototyping. However, to achieve the holy grail of the adaptive enterprise (i.e., adaptive process automation), one needs much more than that -- specifically, business rules engines, e-learning and content management tools, and BI components, all with the foundation of service-oriented architecture. It is the introduction of BRM into the enterprise architecture of their client that makes their experience of particular interest.

Next, Olivier Brousseau of Schlumberger tells us how the oilfield services company challenged the five leading BPM suite suppliers to engage in a BPM proof-of-concept. The part of Brousseau's case study I found the most interesting was when Schlumberger gave the vendors the task of performing one or two process changes, consisting of adding an information item in one of the forms and adding an approval step to be performed by an additional role in the process. This seemingly simple challenge produced some interesting results that will help us assess the current maturity of BPM solutions. Despite his focus on tools, Brousseau views BPM as a discipline that covers both management and technical aspects of process orientation. The most important shift here is a focus on end-to-end processes that span multiple business units. Management of such processes typically requires C-level executive support, as no single business unit would take responsibility for the whole process.

For Mark Fung-A-Fat, our next author, BPM is primarily a management discipline. In fact, he sees any organizational effort aimed at documenting, improving, and better managing business processes as part of BPM. Fung-A-Fat warns us against approaching BPM with the idea that introducing a "magical" packaged solution into an organization will automate all its processes, making them inherently more efficient. He cites three case studies from the Massachusetts Medical Society (MMS) in which successful streamlining of process flows has been achieved using various tools and technologies that we do not typically associate with BPM activities. Interestingly, for Fung-A-Fat, it is BPM that drives 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 BPM buyer a tool for assessing the suitability of a potential BPM suite. The apparent complexity associated with reconciling the needs of the organization and the capabilities of available products stems from the fact that there is no common theoretical foundation for BPM technology, and BPM tool vendors come from diverse backgrounds, such as office automation, traditional workflow systems, tracking systems, and even project management, with its PERT and Gantt charts. What I find to be one of the most sobering conclusions from their research is that standards such as Business Process Modeling Notation (BPMN) and BPEL, instead of ordering, 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 business processes is, to put it simply, tough. To name a few problems, we still don't seem to agree on a theoretical foundation for BPM, there are very complex issues associated with transaction management of long-running processes, and modeling languages lack the formal semantics necessary for easy interoperability. If indeed modern BPM is all about making an organization more agile, then on top of these problems, we add another layer of complexity associated with change. As business processes change, one may need to change underlying services, implying change to applications and systems that expose these services. It is naive to assume that BPM tools by themselves allow for easy process change in an organization. However, moving process logic out of silo application suites, exposing process definition to business users, and augmenting BPM suites with BRM, modern BI, and knowledge management might eventually get us to our vision of IT being able to fully support the adaptive, ever-changing enterprise. We might not be there yet, but we are certainly moving in the right direction. If you want to see in more detail where are we now, what to look for, and where not to get too carried away by marketing hype, read on!

NOTES

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

ABOUT THE AUTHOR