Our recent discussions on process modeling and process execution encouraged me to dig into my archives in order to retrieve some ealier definitions of BPM. I turned to the fantastic Wayback Machine developed by the Internet Archive project, and retrieved an article dated September 2002 that was one of the first attempts at clarifying what BPM really means. If you thought the ‘M’ in BPM referred to the concept of Modeling, think again.

In a research note dated 5 December 1997, Gartner identified “Nine Reasons Why IS Organizations Do Not Do BPM”. At the time, BPM referred to Business Process Modeling, as opposed to Business Process Management.

Five years later, Business Process Management can be viewed as an attempt to address the shortcomings of Business Process Modeling, as can be seen with the following review of Gartner’s objections to BPM’s first incarnation (Courtesy of Gartner):

“Business units will not make the effort.”
By many, Business Process Modeling was presented as an IT-lead initiative that would require the participation of business units for facilitating an increasingly complex software engineering process. Needless to say that business units were indeed quite reluctant to make any effort in that direction.

On the contrary, Business Process Management is conceived as a business-driven initiative that requires the participation of IT organizations for the transformation of business process models into executable processes.

“We tried CASE and did not like it.”
The shortcomings of CASE (Computer-Aided Software Engineering), usually leading to some form of “analysis/paralysis”, are now well understood, and business process management incorporates the lessons learned. BPM is not CASE. CASE was an intermediate step that automated the mapping of business requirements and design parameters into existing software artifacts — objects, components, interfaces and so on.

BPM is a new type of software, not based on objects, but on processes — a new first-class information type — and because this new type is oriented toward the expression of business, BPM does not require the translation steps of CASE. It provides the primitives required for developing complex business logic and computation without conventional software development. It has no need of concepts related to the lifecycle of requirements as traditionally defined, such as application design, implementation, testing, and deployment. In BPM, testing is largely superseded by simulation.

“We do not have the time.”
When used by IT organizations only, Business Process Modeling was often perceived as an unproductive step in the overall software engineering process. Such an additional step was usually incompatible with increasingly tight delivery schedules that were made even worse with the Y2K bug looming to the horizon back in 1997.

Instead, Business Process Management, through its ability to quickly turn a business process model into an executable and manageable process, can be seen as the fastest Rapid Application Development (RAD) methodology ever made available to a community of developers comprised of business analysts and software engineers.

“Business units tell us what to build — we do not question them.”
Business Process Modeling was often presented as a way to address the divide between business and IT, by enabling “a combination of IT push and business pull”. This was ignoring the sheer fact that business units perceive IT organizations as mere cost centers, hence cannot tolerate any push coming from them.

In many ways, Business Process Management is a similar attempt at bridging the gap between business and IT, but resorts to a radically different strategy. Instead of trying to reverse the natural chain of command between business units and IT organizations, Business Process Management streamlines a business-to-IT relationship by delivering to both organizations a common language that enables business units to tell IT organizations what to do, as well as IT organizations to question business units in return.

“We cannot keep business and IT models in synch.”
Originally, Business Process Modeling supported the development of business process models that merely served as specifications for software applications, themselves designed through a traditional software engineering process that usually required the development of ad hoc IT models. This created a discrepancy between business and IT models that were virtually impossible to keep in synch.

Learning from this experience, Business Process Management is based on an architecture that promotes a single model to be shared and preserved over the entire life cycle of any business process. Instead of relying on multiple models and various transformation mechanisms, Business Process Management relies on a unique model and projection technologies that offer multiple views to it: one for business analysts, and one for software engineers. As a result, reverse engineering for model round tripping become something of the past that everybody is more than willing to forget about.

“Business changes too quickly to model it.”
Business Process Modeling’s inability to capture business changes in real time were magnified by two main factors: the need to synchronize business and IT models on one hand, the all-encompassing approach usually adopted by most Business Process Modeling projects on the other.

Because Business Process Management relies on a unique model shared by business units and IT organizations, business processes can more quickly be adapted to the rapid evolutions of business in general. Furthermore, Business Process Management, even though advocating a top-down approach to the management of business processes, does not require the modeling of the entire business for it to be effective. This pragmatic approach to modeling should be considered as one of the key success factors for Business Process Management projects.

“Is Applications Development Modeling not enough?”
Because Business Process Modeling was presented as an IT-lead initiative, it often conflicted with other initiatives that more closely matched the requirements of IT organizations at the time, such as Applications Development Modeling (AD Modeling) — the Unified Modeling Language (UML) being its most successful incarnation within IT organizations.

On the contrary, Business Process Management is conceived as a business-driven initiative that complements on the business side various methodologies that have proven successful on the IT side, such as UML, eXtreme Programming (XP), Service-Oriented Architectures (SOA), etc.

“Is prototyping not enough.”
Because Business Process Modeling was sold to IT organizations rather than business units, the mere concept of business process was often mistaken with processes that are usually manipulated by IT organizations and commonly represented through flowcharts, such as system procedures and screen flows. This lead to the conclusion that Business Process Modeling was just a fancy way to describe application prototyping.

In that respect, Business Process Management does not just pay lip service to the “business” adjective in “business process”, and instead considers the business dimension in business processes as the prevailing one. Even though system procedures and screen flows can fully be captured by Business Process Management as the lowest level of end-to-end business processes, they merely represent the implementation side of an higher-level business process that was initially developed by a community of business analysts.

“Business Process Modeling is more trouble than it is worth.”
For all the objections listed above, many companies eventually came to the conclusion that Business Process Modeling was indeed more trouble than it is worth. This was to be expected from a technology that was targeted at the wrong audience, hence created all kinds of tensions and conflicts both between and within business units and IT organizations.

Most Business Process Modeling vendors actually started as Applications Development Modeling vendors selling tools to IT organizations. Following the Business Process Reengineering wave that took place in the first half of the 90’s, IT organizations were faced with the need to implement newly reengineered processes, hence clearly expressed a need for Business Process Modeling capabilities to their tool vendors. This evolution contributed to create the situation outlined by Gartner’s note.

Interestingly enough, Business Process Modeling vendors learned from this experience and started to shift their targets from IT organizations to business units, effectively preparing the ground for the adoption of Business Process Management by business units and IT organizations altogether.

Today, the leading process modeling tool vendors, including Casewise, IDS-Scheer, Popkin, and Proforma, are even accelerating this transition by actively participating in the development of the Business Process Modeling Notation (BPMN), which will bring the promises of BPM (1st generation) and BPM (2nd generation) closer to reality.

This article appeared in BPM, The Third Wave, which I co-authored (sort of).