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…