thinking makes it so

There is grandeur in this view of life…

Business process architecture and business change #5

leave a comment »

BPMWf2008cover-02This is the last 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

Business process architecture and business change #4

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.

In this article the process meta-model is applied to some real-life examples so as to draw out a few methodology implications.


If we focus on the customer request as the initiating entity then the format the request is in should be secondary. An order could be captured by the customer on a web page, posted or faxed as a form or a letter, telephoned to a call centre, or received by email. The process should cater for all of these. There will be format-specific rules, but also generic rules regardless of format. There should not be one project to develop a ‘web-based order process’ resourced by a ‘web team’ and another ‘back-office order process’ project resourced by a different team.

Below is an example process design for a context where orders and other incoming requests can be received by a variety of channels:

Figure 16

Figure 16

Consider again Organisation Org1 in Figure 8 from Business process architecture and business change #3 (repeated below for convenience):

Figure 8

Figure 8

Organisation Org1 could be a financial services company, where (say) P1 is a loan product and P2 is an investment product. Org1 may not have a purchase order process as such but a range of other processes initiated by different request types: loan application, loan redemption, investment application, investment payout, change of address etc. Again each process would be the same regardless of format or channel, but no doubt with format- or channel-specific rules. So a truly process-based Org1 should not have a ‘web team’ developing a ‘web-based loan system’.

Data and rules

Empirical observation is often key to re-engineering initiatives, whether to understand and measure a process or to identify improvement opportunities. The meta-model provides a framework for structuring the results and, perhaps more fundamentally, a program for what to observe – so as to understand the data and identify the rules.

In the order process the request is the purchase order. Below is an example of a straightforward logical data model which could apply:

Figure 17

Figure 17

An order could be for many products. In the draft process design of Figure 11 (from Business process architecture and business change #4, and repeated below for convenience), when the order gets to Subprocess: Match against stock, some items could be in stock but others not:

Figure 11

Figure 11

We need a rule: can we despatch part orders? We will assume yes, but only if the part order value exceeds a certain parameter.

So our draft design should change to something more like this:

Figure 18

Figure 18

Here one instance of Process: Order creates an instance of Process: Fulfilment for each part order which can be authorised and despatched. Subprocess: Complete order terminates Process: Order when all part orders have completed.

The process implications of part orders may call into question the logic and position of Subprocess: Check credit rating. In both Figure 11 and Figure 18 the assumption is that the value of the whole order is checked against the customer’s credit limit and current balance. But the value of the first part order could be within the credit limit, so maybe the rules should apply at part order level – which would mean a more sophisticated task structure factoring the credit checking rules into Subprocess: Match against stock?

Conclusion: design first

Examples like these show a draft logical process design and draft logical data design being used to tease out and clarify business rules.

It is hard to overstate the significance of this for a process project. This is indeed the elephant in the room. The process meta-model both allows and requires logical design to start early, in order to identify requirements. We do not ‘define process requirements’ and then pass them to a development team for ‘process design’. This is fatal, as business users and business analysts typically define requirements in terms of systems they are familiar with.

Logical design needs to be done by someone who understands data analysis and process architecture. That someone could be called a process analyst or process designer or process architect or process modeller or business analyst or business architect or business modeller. What is crucial is that he or she must understand how process components (request entity, rule, process, sub-process, task) fit together at a logical level in order to engineer a customer-centric process solution which works within the logical data model. A business transformation initiative which has a significant process component will be less successful than it could be if it does not acknowledge this and does not factor it into its project and engagement design.

This approach is very different from familiar systems projects, and both ‘business’ and ‘technology’ people can find it a struggle – particularly if it questions structures of power and influence. (It can be difficult to get a man or woman with a hammer to understand that everything isn’t a nail.) It calls for a holistic engagement and delivery model and holistic data and process design skills. But it works. It avoids massive duplication, and it delivers: because it opens people’s eyes to the elephant.


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

© 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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: