Business process architecture and business change #2
This follows Business process architecture and business change #1 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.
Processes and services
Service-oriented architecture (SOA) is the 21st-Century panacea, the redemption of legacy and proprietary technology. What we have is OK or can be made OK by componentising it. What we can buy is OK as long as its services are exposed. ‘Services’ is business-speak. We have all we need – or have we?
A business needs services, needs to offer services to customers, suppliers and partners. How does a business process relate to a service? Is a process a service or a type of service? Is a process a set of services? Is a service a set of processes? Do we need processes if we have services? We need workflow, because we need people’s work to be organised, distributed and controlled. So is workflow a service, or a set of services?
We have a metamuddle. We want a number of things to be true, and true together.
We want componentised services, and we want them modular and hierarchical. In Figure 2 service B is made from services E and F, while F is made from D and G:
We want end-to-end business processes, and relationships between processes and services. In Figure 3 process BP1 uses services A, F and H, and process BP2 uses B and H:
But we also seem to want ‘business services’, where an organisational entity can provide services to other entities, and perhaps receive revenue for supplying them. See Figure 4:
How do business services BS1-BS5 in Figure 4 relate to processes BP1 and BP2 in Figure 3? Are they the same thing? Or are BS1-BS5 in Figure 4 the same thing as services A, B, C etc in Figure 2?
The vision seems to be of organisational entities controlling portfolios of services and offering them to internal and external customers. They are modular and composable – sets of services assembled into composite services as in Figure 2. But does this work all the way down, so the service portfolio of division D1 in Figure 4 could include (say) services B, E and H in Figure 2; and division D2′ s could include services A, C, D, F and G?
Questions like these are looking for choices rather than answers. At a business-architectural level an organisation must choose its ‘primitives’, its ‘axioms’. Otherwise those accountable for technology architecture will not have clear guidelines to follow or share.
In particular, if the definitions of, and relationships between, service and business process are left undefined the result could be a conceptual free-for-all eating up both real cost and opportunity cost. This kind of thinking is not trivial. It is after all what underpins the debate about how ‘BPM’ and ‘SOA’ can or should work together to deliver business value.
Three models will now be contrasted. It is not that one is right and the others wrong. Nor are they the only models. But they show the kind of choice organisations need to make at a logical architectural level. They may not all hold true for the same place at the same time. Remember also the context: rule-based administration in financial services, government, ordering, contracting etc.
Figure 5 is a model where the reference point is the business process. Processes BP1-BP4 call on one or more componentised services A-H. Some of these will be composite services. Processes BP1-BP4 and services A-H are physically and explicitly implemented. This means that physical solution constructs control and coordinate services A-H within business processes BP1-BP4. Business services do not feature, unless they are the same as business processes.
Figure 6 is a variant of Figure 5 where business services do feature, but as ‘bundles’ of one or more business processes. Business services BS1-BS3 may or may not be physically and explicitly implemented.
Figure 7 is a service-based model, where componentised services A-H are assembled into business services BS1-BS3. Business processes do not feature unless they are the same thing as business services. Componentised services are physically and explicitly implemented, while business services may or may not be.
If business service BS1 is physically and explicitly implemented, solution constructs control and coordinate services A, B, F and H as business service BS1. If BS1 is not physically and explicitly implemented, then operational procedures may instead ensure that when business service BS1 is provided, services A, B, F and H are called upon.
The next article digs deeper into these three models.
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.
© Chris Lawrence 2008.