thinking makes it so

There is grandeur in this view of life…

Business process architecture and business change #1

leave a comment »

BPMWf2008cover-02This is the first 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 www.makeworkmakesense.com.

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.

Introduction

Business process architecture and change methodology are two sides of the same coin. Organisations which know this and know what to do with it will beat the competition. This is why ‘BPM’ is so crucial. But architecture and methodology sound both academic and expensive, so people in organisations are often reluctant to think about them long enough to see the value of the coin.

This paper takes as its point of departure a business process meta-model which has been introduced elsewhere, and elaborated from a number of perspectives.2 3 4 5 6 It is a meta-model which is especially suited to administration contexts like financial services, which are rich in data and rules. It is no accident that these are also contexts where BPM technology predominates.

The meta-model sees a business process as an architectural entity derived from data and rules rather than just an empirical fact to be observed or an artefact decided by negotiated agreement between different supplier stakeholders. The meta-model can support selection, design and configuration of IT systems. It can therefore also support the evaluation of IT systems in the service of business processes.

Systems shape work and how people see work and think about work. Internal and external system support teams employ cognitive models shaped by the systems their careers and incomes depend on. Systems and system ownership have so shaped organizational design and politics that even ‘logical’ architecture and delivery methodologies often only have meaning in terms of systems which happen to be in place.

From a process perspective business IT history was back to front. Recordkeeping came first, with process (‘workflow’) a much later add-on. This was understandable as history. But its unexamined, protectionist, product was less forgivable. This product was back-to-front legacy thinking, thinking which translates the profound tautology process-centric = customer-centric into a complex overhead of duplication and falsehood. Meanwhile Lean and Six Sigma stay aloof and go for soft targets.

But this is not good enough for BPM. This is not the way to beat the competition. A new generation of business analysts is needed, who do not take everything vendors and consultants throw at them. These are analysts who understand that a business is a set of interacting processes; and who understand that a process is an architectural entity derived from data and rules. That is the basis on which we then evaluate what system solutions make sense for a given context – both the systems we have and the systems we do not yet have.

An elephant in context

Business process architecture, or rather the need for it, is like the elephant in the room. We know it’s there but we don’t know what to say about it. Why is this? One reason is the IT investment mantra: reuse, then buy, then build. From a corporate IT customer’s perspective anything that smacks of build – design included – is immediately on the back foot. Product selection meanwhile enjoys the happy end of the continuum, particularly if the product promises to make legacy reusable.

There are good reasons for reuse, buy, build. But it can discourage analytical thinking about business architecture and critical thinking about the alignment between technology and business. If reuse gets the gold medal, then arguments that what you have is OK will be rewarded. If buy gets silver, then discovering that what is for sale is OK will also win Brownie points.

This is not to imply that legacy and proprietary technologies are always bad. That would be absurd. The intention is in any case not to critique legacy or proprietary technologies per se, but to expose assumptions they might encourage or reinforce.

A word on context. Much of the discussion will involve generalizations, but a generalization is not a universal truth. The context is not necessarily all business processes. It is that large subset describable as rule-based administration: financial services, local and central government, purchase ordering, contracting, HR management etc etc. It is a huge domain – as mentioned above, it forms a large part of the potential market for BPM systems in fact.

A brief history

Economic trends affecting business IT over time can be summed up as in Figure 1.

Figure 1

Figure 1

It is no surprise that systems first focused on record-keeping: products, orders, payments, contracts, applications, agents, customers; and then transactions – transactions being event records which change the status of these ‘master’ records. A business process was something people did around (and in interaction with) systems, occasionally fast-tracked by bursts of automation inside or in between the systems themselves.

Then workflow made at least some parts of some offices paperless. A ‘workflow’ is kind of the same thing as a business process and kind of not. Workflow starts when it starts, which might be after the true ‘end-to-end process’ begins. It controls sequences of interaction and distributes work between and within teams. But an important subset of the business rules coded as either data or program logic inside administration systems have process implications. These rules must be duplicated in or somehow accessible to workflow if workflow is to be coherent and comprehensive. Hence the debate about ‘what is a product rule?’, ‘what is a process rule?’, ‘what is a compliance rule?’ etc. And hence the debate about ‘where does process logic belong?’ – as if this was a question about the world like ‘where do fish belong?’.

IT has archaeological strata, but IT systems are not natural kinds. Administration systems are rarely process-architected to any extent – the concept of ‘business process’ is rarely implemented inside them. Even their ‘long-running transactions’ reflect few of the ifs, buts and maybes of a real end-to-end process.

Workflow systems on the other hand typically come from vendors who need their products to be generic like email and spreadsheets. Workflow fits outside or alongside administration systems because it primarily supports, controls, organises and empowers the human users of those systems. Ergo the business process is something people do around administration systems.

But this is a false paradigm, created by IT history. Before exposing it though we must bring our history more up to date. Read on…

References

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 www.makeworkmakesense.com.

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

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.

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: