BPMN and Business Process Architecture

In the past year the "architects" seem to have discovered BPMN. That has been good for the training business, as architects tend to mobilize their organizations on a larger scale than individual project teams do. But I have also found that, despite their fascination with metamodels interconnecting all sorts of information about how the business works, architects tend to have a nebulous - and often incorrect - understanding of the most fundamental BPM concepts, like "activity" and "process". This is a problem, and, it seems to me, a fixable one.

I do not distinguish here between business architects, business process architects, and enterprise architects. I understand they all do somewhat different things, but in this respect their similarities outweigh the differences. Their perspective is fundamentally deconstuctionist, meaning their approach is to take apart the business and sort it into boxes for analysis. By breaking information out of the silos of individual systems and organizational units, this allows better alignment of people, systems, and IT investment generally. That is all good. Architects seem to be more comfortable with concepts like "capabilities" and "value streams", which describe what the business does, than with BPM "processes", which describe how work gets done.

BPM is fundamentally constructionist. It is about assembling pieces of business activity - activities, let's call them - into sequences that accomplish useful work called processes. The word "sequences" is key here, at least for business processes that can be described by BPMN, because it means strict ordering in time.

Activities are actions that perform a specific bit of work. An activity is work performed repeatedly in the course of business, each instance of the activity doing more or less the same sort of work. An activity has a definite start and a definite end. In a process, when one activity ends, the next one in the sequence starts, or is at least ready to start. Assembling activities into processes in this manner requires the activities to"fit" with each other properly. For example, usually there should be a one-to-one correspondence between their instances.

Similarly, a process is also performed repeatedly in the course of business, with a well-defined start and end. Each instance of the process starts in more or less the same initial state and is transformed by the sequence of activities to one of several alternative end states. A process model is a diagram of all possible sequences from that initial state to one of those end states. Whether that process flow is automated or not - and the vast majority are not - this is what BPMN means by a process model.

A major problem with business process architecture, in my view, is adopting the architect's deconstructionist viewpoint at the expense of BPM's constructionist requirement. If you're sorting things into boxes, it doesn't matter so much if some boxes hold square pegs and the others round holes. But when you want to assemble those boxes into a coherent unit, it would be easier if the pegs and holes all had the same shape.

You don't need to break business process architecture to do that, just be aware of this constraint. In the world of business process architecture, there are any number of process classification frameworks out there: SCOR, eTOM, AQPC, etc. Each defines a standard process hierarchy useful for apples-to-apples benchmarking of organizational performance within a specific industry. The top two or three levels are, to my thinking, indistinguishable from functions or capabilities. They are not really processes. At around Level 3 or so they start looking like what BPMN would call processes, although often not end-to-end (customer-facing) processes. And further down they are called "activities", although often not really what BPMN means by activities.

When business process architecture enumerates processes that are not really processes, or activities that are not really activities, usually the problem is that what is enumerated are actually functions or capabilities, not specific actions (or sequences of actions) performed repeatedly in the course of business, with each instance having a well-defined start and end. Even when labeled VERB-NOUN to suggest an action, they may be things performed continuously rather than repeatedly. Activity names starting with "Manage", "Monitor", or "Maintain" typically fall into this category.

Here is an example I use in my BPMN classes. I clipped this bit from AQPC's Process Classification Framework. The third outline level represents "processes", and here I've selected the entry for Process Expense Reimbursements, which I would agree is a process. But two of the nominal activities under that are not really activities in the BPMN sense. (Some students question a third one as well.) Can you tell which ones?

The last one, Manage personal accounts, is definitely a function, not an activity. It doesn't have a well-defined instance or specific start and end. I can imagine a process that could incorporate it - for example, a monthly procedure in the accounting department related to other monthly reporting and payroll activities. But otherwise, no, I don't think so.

How about Capture and report tax data? That seems like two distinct activities. Capturing the tax data is done for each expense report as it is processed, while reporting it is something done quarterly or annually. How is that a single activity? It's not.

The first one, Establish and communicate... [policies], is also possibly two distinct activities. I can imagine businesses where they are done together, but in the general case, establishing policies and communicating them to employees are separate actions, occurring at different frequency.

I don't mean to pick on AQPC specifically. I see this as a problem with business process architecture generally. And it's not just a question of classification aesthetics. It can actually get in the way. An end-to-end (customer-facing) process like order-to-cash ideally should be modeled as a single BPMN process if you can do it, because BPM as a management discipline asks you to conceive of the process as a "single" thing, cutting across the silo boundaries, rather than as a bunch of independent things.

When you cannot do it, it's usually because there is not a one-to-one correspondence and clear time ordering between activities in the end-to-end process. Sometimes that is unavoidable, but often it is just lack of awareness of this constraint in the BP architecture. I have had my BPMN students tell me they are forced by their management to wire together the boxes defined by their BP architecture team, even when it doesn't work in BPMN. If BP architects were more aware of BPMN's conception of activity and process, this problem could be reduced a great deal.

I would like to see the architects' "process" domain reserved for models that respect BPMN's conception of activity and process, with defined relationships to related notions like capabilities, functions, and value stream fragments, rather than blur them together, as they seem to do today. This would go a long way toward unifying "enterprise BPM" with the process modeling standard.