Business Process versus Business Function

A rather tricky part of ArchiMate is the difference between Business Process and Business Function. Both stand for behaviour at the Business Level. Both generally encapsulate in the end the same activities. Choosing between a Business Function and a Business Process is sometimes difficult. Here is how I ended up looking at it. 

Note: the content of this post has been superseded (amended and extended) by the content on this issue in my book Mastering ArchiMate now in its fourth edition. Follow this link to the Edition 3.1 (released in 2021) book page. On that page, you can find a free download of the first section of the book that explains the entire ArchiMate syntax.

Note that the text below has aged well (ArchiMate hasn’t changed much since version 1) but there is much more to say about it. The name ‘Used-By’ for a relation has changed in ArchiMate to ‘Serving’, but is the same relation.

ArchiMate in its prenatal form used to have a concept called Business Activity. This would stand for a lowest level, indivisible, piece of business behaviour, that is, it was not to have any constituent parts. Business Function and Business Process would then be a composition of  business behaviour objects, either Business Function, Business Process or Business Activity. In an ‘unfolded’ picture that lacks the abstract ‘Business Behaviour’ concept, it looks like this:

They dropped activity in the final 1.0 spec. I do not know why exactly, but I can imagine a couple of reasons:

• It is difficult to decide when something becomes indivisible;
• Business Process in ArchiMate is seen as something that is directed at producing a result (service, product) and Business Function as a grouping of behaviour based on resources. A direct composition of Business Functions and Business Processes as composite parts of each other would make this distinction less meaningful.

My initial approach to combining the different roles of Business Function and Business Process in our ArchiMate models was close to this original, but with a small twist. In  our company it is customary to think of Business Processes as being a sort of ‘chain’ of Business Functions and in ArchiMate this becomes a Business Process that has aggregated Business Function children. I proceeded to make that view symmetric in that one could also say that a Business Function aggregates the Business Processes is contributes to:

(I had removed activity as it is not part of ArchiMate 1.0.) In this way, I took our company’s approach and made it nicely symmetric. Both are then just overlapping (not necessarily orthogonal) views of the same business behaviour. Say, a wave/particle view of something that is essentially the same thing, one ‘measured’ from the aspect of what it produces (process, outside-in) and one of what it requires (function, inside-out). I can personally live with that QM-like ambiguity, but it is not to everybody’s liking and it is difficult to ‘loosen up’ the more ‘discrete’ modelers among us. Therefore, I dropped that way for another, because we actually can be more exact in our thinking using ArchiMate’s relations as steering.

So, suppose we do indeed see process as a kind of ‘chaining’ of functions, what are we saying, ArchiMate-wise? Chaining is not an ArchiMate relation, after all.

Luckily, ArchiMate has a good relation for this: Used-By. So, what we can say is that the Business Process uses the Business Functions in some way (instead of both being aggregates of each other). In ArchiMate, how does a process use a function? Well, a Business Process can use a Business Service provided by the Business Function.  But as a Business Service should be best modeled as the result of a Business Process given ArchiMate’s definition of Business Process (it is a process that leads to a result, not a function), we must ask ourselves: what process realizes the service? Well, that must then be the internal process of the Business Function of course. The result is something like this:

Here we see a Business Process that uses two different Business Functions to realize a Business Service. The roles are assigned to the functions, that according to ArchiMate should be performed by a single role. The internal processes of the functions have here been modeled as composites of the function, not aggregates. That is logical, because the internal process of a business function ceases to exist if you delete the business function. You may prefer nesting to strengthen the visual message here. Under water, the composition relation is still there, but showing it embedded is kind of nice in this case:

Now, the question must be asked: which role(s) actually perform(s) “Business Process P”? This depends on the organisation of the company. Maybe there is a steering role for the process (there are problems here, though, see a follow up post). In absence of such a steering role we could think that both Role A and Role B are assigned to Process P. But the (ArchiMate) derived relations between said roles and process from the model above are not Assigned-To but Used-By (performs+composite+realizes+used-by = used-by), so it would be confusing to have both Assigned-To and Used-By from role to process. Therefore, we need another separate role to assign to process P.

One solution (apart from the explicit steering role) is to use a Business Collaboration consisting of the roles in question here to assign to the process. This is not that far from what in reality often happens. In many companies we will see some sort of very loose and thin ‘collaboration’. Payments just pays what Claim Handling has approved and they only communicate when it is about the process or when something is amiss (which in turn is often all that they collaborate about). There is no separate role making sure that that happens. Yes, there are (as oversight) process owner roles for the internal processes of function A and B so their internal process is such that collaboration can actually happen. But these, as we have seen in a previous post, are quite different roles than those that are assigned to performing the function. Anyway, an example of loose/thin collaboration would be something like this:

Depending on how the operating model of your organisation actually is, a different picture may emerge of course.

Finally:

1. If we take the above approach and map it to the application layer, we would get the situation that we might say that an Application Function has its own internal Application Process, a concept that does not exist in ArchiMate. Should it? Application Process realizes Application Service and Application Function is grouped based on Data Objects and Infrastructure Services required? (Note 2021: it exists since ArchiMate 3)
2. Should I instead have modeled the internal process of a business function separate from the business function instead of inside it, going back to the wave/particle approach on what the role performing the business function actually does? Possible, it seems to me there are multiple usable approaches here. The nice thing of (sort of) a language is that there are many ways of saying the same thing and only at the digital level (e.g. application level) must all these ways mathematically be equivalent or they are not ‘the same thing’. In the real world of the business level, where humans act, exactness will remain elusive, whatever your method, language or grammar. Enterprise Architects need to live with that.