Process Mapping

In my last post we discussed domain modelling in the context of SOA, specifically addressing coupling and cohesion. Domain modelling however provides only a static view of our business model. It does not describe how business entities interact over time. For this we look to process mapping.

Now before we get started I'd like to preface this discussion with the disclaimer that I am no process mapping expert. So take what you read here somewhat with a grain of salt.

We can break down the business processes of an organisation in any number of ways. We could for instance start with very high level process maps and then iteratively decompose into lower level process maps until we get down to individual business activities that require no further decomposition.

This process however is not deterministic in nature. Two different business architects independently performing this exercise could produce different sets of completely accurate process maps for the same business. The difference between the two sets of process maps would primarily be where the borders are drawn between process maps. One architect may place logic in one process map that the other may place in another. Overall the same business process is described, but it is broken down in different ways.

As it turns out, there is quite a lot of symmetry between this process mapping exercise and the process of identifying and defining services. That is, we want to define process maps that have high cohesion and loose coupling. Failing to do so results in unstable process maps.

When we have the concerns of a single cohesive business area (described by a cohesive domain model) spread over a number of process maps, then making a change in that single business area will result in a need to update many different process maps. That is, we now have coupling between our process maps. Consequently process maps slowly get out of date due to the amount of effort necessary to keep them in sync with the business.

What we want to do is ensure that each low level process map describes a business process within a single specific cohesive business area. We can use high level process maps to describe how each of these low level process maps interact in support of business processes that span multiple business areas.

For example, consider the following extremely oversimplified high level process map:


We need to assess whether each part of this process pertains to the same cohesive business area. If not, we must subdivide the process further. Let us assume that for this insurance business we decide that the cohesive business areas relevant to this process are Customer Management, Policy Administration and Billing.

We will end up with three cohesive business processes in the following business areas:

Policy Administration


Customer Management


Billing


When it then comes to defining our service model, each cohesive business area becomes a single service. So in the above example, we end up with three services. The domain model and low level process maps that describe that business area then define the responsibilities of that service. The high level process maps tell us how our services must interact, thus helping us define our service contracts.

Note that the above example is quite considerably oversimplified. Real world examples get a lot more complicated very quickly. Process mapping is an extremely challenging task and is not easily done well.

We must be careful with these process mapping and domain modelling exercises not to get caught up in analysis paralysis. Keep the scope of an SOA project small and deliver incrementally. That way you are only ever focussed on the parts of each business area relevant to the specific deliverable at hand.