BPM—The promises and the practice Part 1

By Laurent Lachal

The simplest definition of business process management (BPM) is that it is a process-oriented way of thinking about existing IT systems, and of procuring, designing, building and integrating new systems. Just as object-oriented approaches to software implementation led the software industry in the 1980s and 1990s, so process-oriented thinking, implemented through BPM programs, is set to lead the coming wave of innovation and investment in this decade.

There are three crucial elements to understanding the discipline of BPM:

• Change is "built-in." BPM enables the continuous comprehension and management of business processes, both within and across organizations.

• Business and technology are united. BPM aims to align business processes with the goals and capabilities of the people and systems that are involved in their execution.

• It is about much more than technology. Doing BPM right requires that you bind a process-oriented change and design methodology, and a high-level enterprise architecture practice, together with process-oriented software technology implementation initiatives.

The promises of BPM

Four main benefits are derived from the successful implementation of BPM:

• It makes understanding the sourcing jigsaw (what to outsource and what to keep in-house) easier. This is the perfect opportunity to consider which functions are utility and which ones are differentiating areas of value-added. For the former, the day is fast approaching (and many would argue is already here) when outsourcing in one form or another makes strong business sense. For the latter, BPM holds the promise of enabling IT and business executives to co-operate and retain management control over the business process, irrespective of where the underlying IT resides.

• It improves your business agility. Such agility doesn't just come from automating business processes; it also stems from the fact that a process-oriented approach to thinking about IT enables a clearer division of responsibility between IT staff and line-of-business staff. BPM enables much better co-operation between business managers (in charge of business processes) and IT professionals (in charge of the IT assets that deliver the services underpinning the processes) when it comes to defining IT requirements and change requests.

• It removes technology stovepipes and silos. More often than not, user organizations are a hodgepodge of silos unable to handle the end-to-end automation of business processes--and so are their IT architecture practices and business applications. BPM advocates promise that BPM will sweep away silos and stovepipes, from both business and IT perspectives. That is only truly achievable if you can completely re-engineer all your existing IT systems in line with the requirements and restrictions of a BPM approach. Not many organizations will be able to do that within the next five years.

• It enables immediate change of IT systems in line with new or changed business requirements. BPM advocates assert that by implementing a business process management system (BPMS), and using it to manage the execution of all your automated business processes, you will be able to model processes. You will then be able to dynamically implement changes to the operation of IT assets, as business requirements are refined or modified. As with the promise of sweeping away today's silos and stovepipes, the promise of enabling immediate change is only achievable when you re-engineer your existing systems and when BPM technology matures enough to handle it.

Connecting business and technology

There is nothing new about the idea of modeling and analyzing a business by examining the processes in which it engages. Management consultants have been using business process analysis to help companies improve themselves for decades. Therefore, what makes BPM so interesting?

Software design methodologies in the 1970s focused on how to model data structures and function structures separately, because that was how systems were implemented. With the rise of object-oriented methodologies in the 1980s, software design approaches evolved to consider binding function and data together in systems that could more closely model real-world scenarios. That enabled software design approaches to map much more closely onto the application development requirements brought about by the new, rich user interface systems that were being developed.

Once again, the environment and requirements for analysis methods have changed. As automation has penetrated every function of the enterprise, computing resources and the users of those resources have become much more distributed through time and space. The process-oriented BPM approach addresses that change by considering the dependencies between data, function and business processes together.

It is only by modeling business processes (which formalize and co-ordinate links between distributed computing resources and their users) in the context of existing software structures (functions and data) that IT organizations can start to bridge the gap between business and technology, and so realize the big BPM promise. Previous attempts to automate business processes--notably workflow technology--failed to really bridge the gap between business and technology, because workflow takes a process-only view of the world, and avoids trying to unify business processes with data and function.

The purists and the pragmatists

In the object-oriented revolution of enterprise software in the 1990s, the Object Management Group (omg.org) led the evangelism of object-oriented theory, while many existing software vendors advocated a more evolutionary approach to achieving the same benefits. Then, as now, the market was split into purists and pragmatists.

This time round, the purists are spearheaded by a relatively new industry group called the BPM Initiative (BPMI, bpmi.org). That group was founded by CSC (csc.com), which played a major role in the BPR boom of the 1990s, together with a handful of small, specialist start-up software vendors. Its membership has now widened to include a handful of large user organizations (including France Telecom, francetelecom.com), other systems integrators (including EDS, eds.com, and Cap Gemini Ernst & Young, cgey.com), and other software vendors (including BEA, bea.com).

The pragmatists in the BPM movement are, to put it bluntly, everyone else.

The purists advocate use of a new type of software.

The BPMI purists make a very straightforward link between the theory of BPM--the unity of business process, function and data—and the actual software required to implement BPM within an organization. The BPMI advocates the use of a runtime system called a business process management system, which is a specialized platform for managing electronic business processes—similar to today's DBMS' roles with respect to managing electronic data.

The theoretical foundation of BPMI's work partly relies on pi-Calculus whose conceptual father is the well-known computer scientist Robin Milner. Whereas today's procedural software development languages are based on a theoretical foundation called Lambda-Calculus, pi-Calculus takes a different perspective. Instead of modeling how functions operate on data, pi-Calculus models how functions communicate with each other using messages. Accordingly, pi-Calculus unifies computing (what happens inside a computer) with communication (what happens between computing systems). Pi-Calculus considers all processes as acts of communication.

In theory, a dedicated, specialized BPMS frees you from the constraints that existing systems (such as workflow engines) place on the kinds of business processes that you can model and execute. The BPMI also claims that the coming rise of the BPMS, and the calculus that underpins it, will reinvent software design as we know it.

The BPMI's approach has three major consequences:

• It enables you to represent and automate any processes, ranging from ad hoc collaboration to highly structured transactional processes, within one environment--including those processes currently executed via workflow, enterprise application integration (EAI), e-mail collaboration, B2B platform software, etc.

• It turns everything into a process--including a GUI or a calculation. For example, not only is the equation 1+2=3 a process but 1, 2, 3, as well as + and = are also processes. Similarly, a GUI is a process, and so is each graphical field in a GUI window. The file that contains all your medical history is no longer the '"thing" moved along by the process. It is the process itself that interacts with other processes in the medical ecosystem.

• It frees you from the need to hard-code software to implement a business process; processes are no longer embedded in software code that is difficult to change. Instead, they are directly executed by the BPMS. Process execution occurs through the communication of parts, not the execution of code. Within the BPMS, individual process instances can adapt, combine and split on the fly.

The pragmatists take a different approach.

The complete reinvention of software design is a truly remarkable ambition, which explains why the pragmatists in this debate (which are most software vendors) are trying to deny that BPM will have such an impact. Rather, the pragmatists explain BPM initiatives as an incremental step in the evolution of enterprise software, rather than as a revolution.

The pragmatists have learned from the challenges of the object-oriented revolution, which actually took a long time to affect the established modes of building software. Instead of preaching a software revolution, the pragmatists are busy building process-oriented extensions to existing types of software products--including enterprise application software, workflow engines, application integration suites, business intelligence suites, application servers and application development tools.

The downside of this evolution, however, is that it makes a very confusing situation for anyone trying to understand how to go about implementing a BPM initiative with software technology. Once everything starts to look like it is a BPM product, how can users make sensible choices?

The road to process-centric IT

Given that some of the promised benefits of BPM implementation can only be realized once you have driven BPM technology through the heart not only of your IT staff, but also all your existing IT systems, are there any benefits that can be achieved along the road to BPM implementation? Or is BPM a big-bang proposition? Luckily, the answer is that real and valuable benefits can be realized as you travel the road to process-centric IT. You can achieve them as long as you take a measured, methodical approach to implementing BPM. The chart summarizes the steps you should take and the benefits that you can realize at each step.

The current BPM preoccupation with technology is dangerous because:

• Technology (particularly BPMS technology) doesn't come into the picture until a lot of work has already been done.

• Getting the maximum value out of the technology requires you to drive change at a cultural level within the business, as well as within the IT department, and that is actually far harder than implementing and managing software systems. What makes BPM different from BPR is its upfront embracing of and encouragement of the development of supporting software tools for a business methodology. However, that may prove to be an "own goal" if the market concludes that it simply needs a new technology solution (the BPMS) and ignores the requirement for the sophisticated business analysis and change management techniques to make BPM work. As the chart shows, you need to approach BPM from three perspectives, in the following order:

• Methodology—You do not need software to do that, just determination and careful planning to define, for example, which processes are key to your competitive advantage and which ones are not; which processes to focus on and which ones that can wait, and so on. Success with BPM will depend as much on the caliber of business analysis and change management available as on the caliber of the supporting software architecture and products. More so than in any other software areas, the culture of your organization, rather than technology, is the main BPM pain point.

• Architecture—Your BPM initiative will benefit from an enterprise architecture model built on service-oriented architecture (SOA) principles and Web services technology. Implementing such an enterprise architecture model will be a multiyear project, because the technologies involved are still immature. Also the presence of a clearly separated process infrastructure layer within an enterprise architecture model does not mean that the impact of BPM is limited to the process infrastructure layer. The architectural aspects of BPM are also concerned with how the process infrastructure layer relies on and interacts with other infrastructure layers. Equally, the presence of a process infrastructure layer does not imply that all software processes should reside in the process infrastructure layer. The reality is that processes are everywhere. They not only reside in other infrastructure layers, but in various organizations--some belonging to your own company (such as subsidiaries and joint ventures), others fully independent of it (such as suppliers and customers). It will make sense to leave some processes in other infrastructure layers or outsource them to other organizations.

• Technology and products--We will provide more information on this in Part 2 of this article.

Most vendors talk about BPM without clearly defining their perspective, or changing perspective while talking about it. You should tackle BPM from all three of those perspectives.

---

Laurent Lachal is a senior analyst specializing in business process management at Ovum (ovum.com), e-mail lal@ovum.com.