Go Flow

Found another interesting and thoughtful discussion of terminology: Workflow or Process Management. I like the six sided cube analogy, and I agree that BPM includes all those aspects. In this view again "workflow" is equated with the human dimension. The only critique I have of the post is: once you include all 6 facets, is there anything in the technical universe that is NOT BPM? This is then simplified to "Automate, Integrate, and Manage" which is similarly all encompassing.

I liked Phil Gilbert's summary of the BPM Thinktank: It's The People, Stupid! Phil's point is that technology (and related standards) is not the key factor in business process management success, but rather the people implementing it. So, BPM is not "Fire and Forget". (Sorry Phil, another military metaphor. )

Without the human dimension, then what is "BPM" anyway? How can one claim the "B" part BPM without workflow? And thus we spiral to a rathole of circular logic.

It seems to me that this particular rathole is a consequence of attempting to define BPM by the things that compose it. This reductionist thinking is natural in high tech circles, especially those with a training in standard programming languages. (Myself included.)

Alternately we take a more holistic view and define BPM/workflow by the results that it produces: organizations that work more effectively and more efficiently; supporting people working in a more coordinated manner. This is similarly useless because essentially anything can be part of making an organization more efficient. For example, pencil and paper fall into this category.

Perhaps the best approach is to define BPM/workflow by what it is not. Clearly it is information technology, and does not move anything physical. It should be something beyond simple programming, so it is not a 3GL like Java, VB, or C++. It is not the storage or retrieval of data or documents because that is handled by databases and document management facilities. It is not basic communications protocols, because that is provided by TCP/IP and more increasingly things known as SOAP and WebServices.

Once you have removed all of the things that are not BPM, what is left? BPM/workflow is a philosophical approach to producing applications that allow people to work in a more coordinated manner. That approach starts with a model, but not just any model: it must be a model of the business aspects of the organization that will use it. The model must be time-aware in a way that standard programming models are not: it represents not only transactions that take time, but it must represent concepts of deadlines that are relevant to people and legal agreements. The model must be useful to business people both in training, understanding current status, and agility. A BPMS should have connectivity to components outside of itself, and those components should not be considered part of the BPM/workflow. These are all things that BPM/workflow uniquely adds to the approach to application development, that are not available in a non-BPM development environment.

The above definition is consistent with Bruce Silver's comments in The Phony “War” Between BPM and SOA. I completely agree with Bruce that BPM and SOA are natural allies, not enemies. SOA is quite simply about how you structure your enterprise application, and that you use open standard protocols to link the pieces. SOA says nothing about having a business-relevant model, or which philosophical approach you take to building your application. SOA is another one of those things that BPM is not. Yet, BPM and SOA are perfectly compatible for developing applications that help people to coordinate their work and make their organization more efficient and effective.

At the last WfMC committee meeting, we were honored by a visit from Skip Ellis, a luminary in the field for 25 years. Huh? I hear some of you exclaim. There wasn't any BPM 25 years ago! Let me explain.

During the 1970's people got the idea that information technology (called simply "computers" back then) could be used to support people at work. The idea is that the computer would figure out what needs to be done, and tell people when they needed to do something, and to provide the tools to easily accomplish the task. There was no internet (well, there WAS an internet actually but it was really really unknown) so it was not clear at all how to accomplish this. Local area networks were virtually unknown except in the rarefied air of places like PARC. But still there was the dream that computers could be used to organize human work and make things easier. It was called Office Automation.

In 1980 Skip was working on the Office-Talk system at Xerox PARC. Read this abstract from his 1982 paper about OfficeTalk-D and see if it seems familiar:

WHAT: Herein is described an experimental Office Information System designed and built at the Xerox Palo Alto Research Center to allow multi-computer experiments in distribution and sharing of control within an office environment.

WHY: Current office systems go a long way toward aiding the individual user to transact his/her personal office work. Future office information systems need to aid tightly coupled communities of users. Thus, this investigation into communal computing systems is motivated.

HOW: Using the Alto/Dorado machines, and the Cedar database and programming environment, we have devised a system which allows the flexible manipulation of electronic forms on the display screen of users and helps to coordinate and control the flow of forms between user workstations. Novel facilities implemented in the system include distributed schedulers, dispatchers, office observer workstations, alerters, a data dictionary synthesizer, change agents, and on-line office modeling, simulation and design facilities.

Many of the terms have changed over the years. We no longer talk about "schedulers and dispatchers" but instead "back-office integration" which is accomplished today with web services. It speaks of forms that are displayed to users, and routed between users. Most notably, it has what we would today call business process modeling, design, and simulation. All this in 1982. Mind you, the hardware and software were very primitive but the dream was there and executed to the extent that the technology of the time would allow.

The term Office Automation (OA) makes me shudder with visions of a Jetson lifestyle where each office has a big red button, and worker's job is to press the button. The term was popular in the 1980's but faded when people found that work was just plain hard to automate, or if you did automate it, you were stuck doing something that was not quite what you intended, or you were unable to respond to change. Soon, the inflated expectations turned into disappointment, and the term Office Automation became "the old stuff that we no longer do".

The new term for the 1990's was "Workflow". The goal was pretty much the same: use information systems to help people figure out what needs to be done, and tell people when they needed to do something, and to provide the tools to easily accomplish the task. The best summary for the 1990s is the WfMC Workflow Architecture document by another luminary, Dave Hollingsworth. Another organization promoting the study of Computer Supported Cooperative Work was the ACM SIGGROUP with which both Skip and I were associated in the early 1990's.

Dozens of workflow products appeared in the 1990s. Also, the Internet happened. Forward thinking people jumped into workflow and many expected their workplace to become more or less instantly automated. As you can imagine, they were disappointed when their inflated expectations were not met, and the term "workflow" became "the old stuff that we no longer do".

But the dream was still there, and rose from the ashes in the form of BPM for the 2000's. Wikipedia offers this description of BPM:

Although it can be said that organizations have always been using BPM, a new impetus based on the advent of software tools (business process management systems or BPMS) which allow for the direct execution of the business processes without a costly and time intensive development of the required software. In addition, these tools can also monitor the execution of the business processes, providing managers of an organization with the means to analyze their performance and make changes to the original processes in real-time. Using a BPMS the modified process can then be merged into the current business process atmosphere.

The activities which constitute business process management can be grouped into three categories: design, execution and monitoring.

If you disregard the changes in the terms over 25 years, you find we are still we are struggling to support the same goals, but now we can do it on hardware and systems that seem infinitely more powerful. The technology today is so much more powerful than it was back in 1980, and a BPMS today does so much more much more easily than was possible with OfficeTalk-D. Still, our offices are not instantly automated. The inflated expectations of BPM are beginning to fade, and people are looking for something new, or at least a new term, and BPM will become "the old stuff that we no longer do".

After 25 years, Skip is still working on BPM/Workflow, now as a professor at at University of Colorado in Boulder. He contines to work on some really interesting things, including some recent papers with Kwanghoon Kim (the WfMC Country Chairperson for Korea) and Jacques Wainer (another luminary) on the subject of analytical mining of the monitoring event data from a BPMS. There is some related work on standardizing those events so that they can be collected from multiple different BPMS and search or alayzed together.  Skip wrote a chapter in the 2006 Workflow Handbook. and came to present at the WfMC speaker session at the Philadelphia AIIM show. 

He has a really great perspective on practical aspects of supporting office work: the real work going on at offices is surprisingly complex and rich while at the same time being intuitive to the workers. It is clear that no technical fix will make all work automatic anytime soon. While we have come a long way in making workers more effective in the workplace, even to the point that a many modern enterprises would not be viable without BPM and Workflow, but there are still many more opportunities for improvement to be found, maybe in the next 25 years.

I ran a "Round Table" at the BPM ThinkTank on the subject of BPMN and XPDL. There always is the question: "Why not use BPEL?" Then I explain how XPDL holds the graphical layout, the X & Y coordinates, the size the nodes, the paths of the lines. BPEL has not support for the graphical layout.

"But you don't need to save the graphical layout!"

This emphatic comment came from one attendee. I truly appreciate the sincerity of the statement, while at the same time it unsettled me. After all, I had just explained that the advantage of XPDL is that you can exchange progress diagrams, and here he was saying there is no need for that. This is not the first nor the last time I will hear this.

"Need" is directly related to your expectation of "use". Many people approach business processes with the mind set that the process diagram is just the starting point, and this will be converted to a set of instructions that will coordinate information flows. This is very much like the role that UML takes in traditional 3GL programming: you start with a diagram, you flesh it out, you eventually switch to filling in the code, then you end up with executable code. With the UML style MDA, you don't need the original diagram in order to execute the final program.

It is my impression that many many people believe that BPM is just an extension of this kind of programming style. The diagram is just the initial phase. Then that diagram is converted to executable code (in many cases BPEL) and then shipped to the execution engine. During the transform, the process is reduced to a set of low level instructions. Look at what the basic instructions in BPEL can do: send XML to some server, read XML from some server, transform XML. Once you have reduced the process to this level, why would anyone need to "see" the process execute? An opaque server is fine, as long as it responds correctly to all the incoming events, and sends out the proper responses. This is the approach promoted by Microsoft, IBM, Oracle, and SAP. This is a traditional "Enterprise Application Integration" approach. And for the EAI worldview, it is true: you don't need to save the process diagram layout details.

Many readers will basically agree with the above, but many will vehemently disagree. There is a large community of people who believe that BPM can be something that is fundamentally different from traditional programming. I have mentioned in other posts the difficulty of naming this. Let's call it "human oriented BPM" or "workflow oriented BPM" for now.

What is different about Human Oriented BPM?

In human oriented BPM, the diagram matters. People are doing the tasks, and people are not like services which simply take a set of input parameters and transform them to output values. People need to understand the purpose of the work, and a little bit about what others are going to do both before and after their task. The diagram is designed as somethign that can represent the responsibilities of different people at different points. This diagram helps people to coordinate what they are doing with what the others do. The diagram is not simple a convenient first step in producing a program. Instead, it is an essential part of the final application.

With Human Oriented BPM, the human action retains its identity throughout enactment of the process. Say you have a business process instance which has not completed yet. With human oriented BPM you can ask at any time the question: Why is this process not completed, and who is "holding the ball"?

Human BPMS supports change. Since processes often take a long time (e.g. 3 to 9 months or more) a Human Oriented BPMS needs to answer "who is holding the ball" not just because people are curious, but because the responsibilities that people hold may change over the time span of the process. You might find that the person holding the ball is no longer in that organization.

A Human BPMS must have the ability to reassign that task to a new person, which means that the system must not lose the identity of the task. For example, an EAI oriented BPMS might take a human level task, and break it into a sequence of data level operations, such as update an account, send an email, mark a tracking record. Reassignment can mean undoing all the small steps that are associated with the "task", and redoing them for the new person. This is not impossible in an EAI Oriented BPMS, I am just pointing out that the identity of a task must be maintained.

A Human BPMS must be able to identify performance of the human level tasks within the process. Even if the human task is broken into a set of lower level operations, the detail of the performance of the operations is "noise" that detracts from the performance of the human activities. If a particular department is responsible for reviewing contracts, a business user wants to know statistics about how quickly those reviews are completed, and not necessarily how well their document management system transfers the documents. Somehow, even in the analytics, the human activities must not lose their identity.

This does not completely distinguish a Human BPMS from an EAI BPMS, so I will have to come back to this in a future post.

I hope at least that this makes it clear that that a key aspect of a Human BPM is that the process diagram is a diagram of the responsibilities of different people, and that the human level task maintains its identity throughout the enactment of the process. In a human BPMS, we don't simply throw out the diagram and replace it with the equivalent set of low level operations, but the diagram itself is a fundamental part of the application.