thinking makes it so

There is grandeur in this view of life…

Business process architecture and business change #4

leave a comment »

BPMWf2008cover-02This is the fourth in a series of articles adapted from a paper on Business Process Architecture and Business Transformation [Lawrence (2008)1] which appeared in the 2008 BPM and Workflow Handbook published by the Workflow Management Coalition (WfMC). The full paper is available from

Previous articles in the series:

Business process architecture and business change #1

Business process architecture and business change #2

Business process architecture and business change #3

The series explores the relationship between logical process architecture and business change. As in the earlier series on Business processes and business rules the discussion employs a proven business process meta-model. The meta-model is one not derived from technology, but from an analysis of what it is to be a business process.

Business process architecture as a methodology

The intention is not to demolish all other models so as to leave just one standing. Instead the benefits of a particular model will be offered as a way of navigating through choices and providing clear methodology and architecture guidelines.

The model is based on the premise that the business process comes first. The business process is not just what people do as they interact with systems. Nor is it just what systems do between user interactions. Nor is it a combination of the two – except in the case of a process-architected solution where the physical model corresponds exactly to the logical process model.

The model has been described in detail elsewhere.2 3 4 5 6 So the focus here will be on the implications of employing it within a development and transformation initiative.

For convenience we repeat Figure 8 from Business process architecture and business change #3:

Figure 8

Figure 8

We start with organisation Org1 in Figure 8. Consider a project scope covering one or more end-to-end processes spanning front office D1.1 and the two back offices D1.2 and D1.3. The sales remuneration department D2.1 may also be affected.

An early question will be on project resourcing. Should the project primarily involve the front-office team D3.1 – as processes start in the front office? Or perhaps the workflow team D3.5 – as all processes involve workflow? Or product support teams D3.2 and D3.3 – considering that systems S2 and S3 handle most of the process detail, so those teams hold and control most of the relevant knowledge?

We need only ask questions like these to see what possible answers imply. Let’s assume Org1 is bold enough to set up a new team D3.6 including members from at least teams D3.1-3 and D3.5. An immediate risk is that a large and powerful group of people will be left behind in teams D3.1-3 and D3.5. This group, along with client colleagues in departments D1.1-3 and supplier colleagues in Org2, may want to see team D3.6’s process project fail. They will not say that of course. More likely they will rubbish the process team’s methodology.

We need to say a bit about what that methodology might be, as it would be one designed for just such a project as this.

The methodology starts by qualifying a familiar generic model:

Figure 9

Figure 9

In the case of a business process there is advantage in identifying a specific input (the request) and a specific output (the outcome):

Figure 10

Figure 10

The model in Figure 10 has three immediate benefits:

(i) It is customer-centric: the request is typically from a customer; the outcome typically for the customer.

(ii) The request and outcome are linked: the request is for the outcome; the outcome is typically the thing requested.

(iii) The request can be understood as a data entity belonging to the organisation’s logical data model, therefore with foreign keys to other business entities.

The link (ii) between request and outcome borders on identity – the relationship is certainly close enough to draw a key architectural implication. This is that the request entity initiates the process and changes status as it passes through the process, until the last status change of all, representing the outcome.

The next steps bring in business rules. A process is a sequence of status changes from request to outcome, and the status changes are governed by rules. The rules applicable to all request entities of the relevant type (eg all orders, for a purchase order process) split the process into subprocesses:

Figure 11

Figure 11

Subprocesses are typically sequential, but could be in parallel if that is what the rules specify. For example Subprocess: Check credit rating could run parallel to Subprocess: Match against stock. The BPMN notation in Figure 11 is ultimately just another way of saying:

First take the order.

Then check the order.

Then check the customer’s credit rating.


The third and final level is task. A subprocess consists of one or more tasks plus the routing between them. Where subprocess-level routing applies to all request entities for the process, task-level routing differs for different request entities. This is because the attributes of the request instances may have different values. The task structure of the process must accommodate every possible request instance. A request instance will typically pass through every subprocess, but only through the tasks it needs to pass through.

A task could be automatic:

All data available; next status change achieved by applying rules mechanically

Or it could be manual:

Human interaction needed, eg because data is missing, authorisation is required, or a decision must be made

Figure 12

Figure 12

Figure 12 shows a simple task structure for the first two subprocesses – allowing manual data capture, automated validation, and correction of validation errors.

It is important to see the model free from existing systems. This is not to say we are throwing everything out and starting from scratch, but to provide a basis for evaluation and a target to aim at.

The model is at request entity instance level – the individual order. If implemented it would provide complete control over each instance, regardless of attribute values. This is true by definition, as the task structure is designed to handle every possible combination of values. The task structure of Subprocess: Check order in Figure 12 only allows well-formed orders to progress further. The task structure of Subprocess: Check credit rating in Figure 13 (below) automatically passes orders already satisfying the organisation’s credit rules to Subprocess: Match against stock. It routes all others to a manual task where an authorised user applies discretion and/or communicates with the customer (for eg advance payment or a bank reference justifying increase in credit limit):

Figure 13

Figure 13

Each subprocess (except perhaps the first if the request entity can only be captured manually) will typically have a controlling automatic task representing the ‘straight-through processing’ (STP) route. STP is at subprocess level: an error-free order would pass straight through Task: Auto check order in Figure 12 but might need manual credit authorisation in Task: Manual credit check in Figure 13. It might then pass straight through a Task: Auto match against stock (not illustrated) because the ordered goods are in stock, and so on.

Relating this now to existing systems we could envisage a ‘purchase order system’ providing, say, a screen to capture orders (the main part of Task: Manual take order in Figure 12), but where the only data validation (Task: Auto check order and Task: Manual correct errors in Figure 12) is within the capture screen itself. This might mean an incomplete order cannot be captured – following the garbage-in-garbage-out (GIGO) design principle.

There might also be a workflow system presenting scanned purchase orders to users for data capture, but the purchase order which is the controlling entity in workflow is a physically different data record from the purchase order captured in the order system. It must be different in the example just given because it exists in workflow but has not yet been accepted by the order system. It may also be a different entity logically – in workflow it may be a document (image) whereas in the order system it is a data set including foreign keys to customer, product etc.

More generally, a workflow system might typically focus on user interactions. In our model these would be:

Task: Manual take order

Task: Manual correct errors

Task: Manual credit check

Task: Manual record reply


The workflow system could have a queue structure something like this:

Figure 14

Figure 14

Figure 13 applies the same design principles to show a rather more complex structure for the third subprocess.

Meanwhile the likely home for the data and rules featuring in Task: Auto check order, Task: Auto credit check, Task: Auto match against stock etc would be the purchase order system itself. So must we have two processes implemented or reflected, one in each system? How do they keep in step? Is one always in control, and if so, which one?

These issues arise not from ‘poor design’, but from IT history following IT economics: record-keeping first, then generic workflow. Now that storage and transaction costs have dropped to make integrated, instance-level process support economically viable (and competitively vital) we have two obstacles. One is ‘how to get there from here’: the recalcitrant legacy architectures we must navigate. The more insidious obstacle though is legacy thinking – the assumption that the reasons system boundaries and system design are as they are must hold true for all time.

The model depicted in Figure 10 to Figure 13 may also not hold true for all time, but it is a far more effective response to current IT economics and competitive pressures. It can be implemented given appropriate BPM and SOA architectures. The cost and difficulty of ‘getting there from here’ are constraints on logistics and phased delivery, not reasons for rejecting it.

We relate this now to the componentised services of Figure 5 from Business process architecture and business change #2 (duplicated below for convenience):

Figure 5

Figure 5

This brings us to an overall schematic like this:

Figure 15

Figure 15

The final step should now be obvious: task is the fundamental unit of a business process, so componentised services link to tasks. We thus have a framework for logical and physical architecture and delivery methodology, which suits process-based transformation projects. It also avoids both supplier-centric legacy thinking and the kind of empirical, anti-architectural pragmatism which too often drives Lean-type process re-engineering.

These last two are related. It is tempting to assume that, because business processes are generally poorly implemented in IT systems, business processes must be ‘something else’, something people do with systems, or the bits in between system functionality. That ‘something else’ is a popular target of Lean-type transformations which pride themselves on not getting bogged down in IT development backlogs.

There is nothing wrong with Lean engineering. Process architecture is Lean by design. The problem is empirically based re-engineering initiatives which see a process as a de facto sequence of improvable activities, but which lack the analytical tools and/or appetite to cut through layers of technology to see the data and rules beneath.

Seeing or not seeing a logical process model is like seeing or not seeing a logical data model. In a forest it is breathtaking how close you can be to an elephant before you realise it has been there all along.

In the next article we will apply the meta-model to some real-life examples so as to draw out a few methodology implications.


1 Lawrence, C.P. (2008). Business Process Architecture and Business Transformation.  In Layna Fischer (Ed.), BPM & Workflow handbook 2008. Lighthouse Point, Florida: Future Strategies Inc, in association with the Workflow Management Coalition. The paper is available from

2 Lawrence, C. P. (2005a). Make work make sense: An introduction to business process architecture. Cape Town, South Africa: Future Managers (Pty) Ltd. (

3 Lawrence, C. P. (2005b). Integrated function and workflow. In Layna Fischer (Ed.), Workflow handbook 2005. Lighthouse Point, Florida: Future Strategies Inc, in association with the Workflow Management Coalition.

4 Lawrence, C. P. (2007a). Business process architecture and the Workflow Reference Model. In Layna Fischer (Ed.), BPM & Workflow handbook 2007. Lighthouse Point, Florida: Future Strategies Inc, in association with the Workflow Management Coalition.

5 Lawrence, C. P. (2007b). Architecture-driven business transformation. In Pallab Saha (Ed.), Handbook of enterprise systems architecture in practice. Hershey, Pennsylvania: Idea Group Inc.

6 Lawrence, C. P. (2007c). Business process integration in a knowledge-intensive service industry. In Wing Lam & Venky Shankararaman (Ed.), Enterprise architecture and integration: Methods, implementation, and technologies. Hershey, Pennsylvania: Idea Group Inc.

© Chris Lawrence 2008.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: