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.


  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.


  1. ArchiMate 1.0 still includes Business Activity – See section 10.2 Specialization of Concepts.
    EA tools such as BiZZdesign Architect also include it as part of the standard ArchiMate.

    It is really confusing to show Business Processes aggregating Business Functions. This is not best practice and should be discouraged. The opposite is the normal way of modelling Business Functions – A Business Function aggregates a number of Business Processes.
    A Business Process doesn’t use a Business Function but forms part of the way a Business Function is realised. See my post at

    A Business Function is a higher level grouping closely associated with Organisation Units, and are usually given names ending in ‘Management’ for example ‘Finance Management’ or ‘Product Management’. A Business Process on the other hand is more detailed and will usually have a name in a ‘Verb + Noun Phrase’ naming convention, for example ‘Create Account’. Business Processes can represent Value Chains, Value Streams and individual Business Processes in various composition or aggregation hierarchies.

    A Business Activity is simply an alternative name for an elementary Business Process (i.e. a sub process at the lowest level of decomposition) and essentially a redundant concept. Since BPMN refers to Business Processes as Activities, so there can be some benefit (in terms of better communication) to using Activities when aligning an ArchiMate model with a more detailed BPMN model.

    In addition Business Functions are commonly used (some say misused) to represent Business Capabilities and these are groupings of a set of other object types from across the rest of ArchiMate layers they will almost never be at a lower level of detail than Business Processes.

    It’s worth remembering that although ArchiMate does deliberately allow for significant flexibility in how Behaviour is modelled, it’s much better to follow best practice rather than introduce local standards.

    Liked by 1 person

    1. Thank you for your comment.

      Business Activity is mentioned as an example to define new concepts based on the existing ones. It is not mentioned as a basic concept of ArchiMate, but it is mentioned as a possibility to define new concepts as an addition to ArchiMate (that is what 10.2 is about, the ‘existing concepts’ in ArchiMate’s business level are mentioned in chapter 4 instead).

      As you might have noticed, my Business Function also aggregates processes (stronger even: composite) so I agree with you here that that is proper. A Business Function has processes.

      There are higher level processes in an organisation that are comprised of activities in multiple Business Functions, e.g. the often mentioned ‘Handle Claim’ process, that is the result of activities in multiple Business Functions (e.g. Receive Customer Requests, Judge Claims, Finance (Make Payments). Such a high-level process is what in the end produces the product or service that the outside world sees and it is not an internal process of a single Business Function. As services and products seen on the outside require a (high-level) process to realize them, and these processes require activities in multiple Business Functions, we seem to have some sort of aggregate (though I did not model it as aggregate in the end, but as Used-By, so I did not say one should model a Business Process as aggregating Business Functions as you state, only as an example that in the end was not chosen.

      For the rest, using the argument of something being ‘best practice’ or a ‘local standard’ is not really an argument when discussing what good practices are and how you can do things. Better/Best practices can only develop when something is done different from existing practice, which inevitably begins somewhere as a local idea. Progress requires it. And bad ideas die in the end because they turn out to be bad ideas.


    1. I have commented on those posts (comments are awaiting moderation as I type this). I have not read everything of that method (IMM) in detail, but restricting yourself to two layers (‘elemental’ functions and the processes that are built from them) is a popular, but in my view too restricted approach. I see a russian doll of processes inside functions used by processes inside functions etc.

      Anyway, “The World’s Only Fully Integrated Business Systems Modeling Method” is quite a claim. As far as modeling goes, ArchiMate is pretty integrated too. But maybe he also has model governance in his method.


  2. I think this distinction between the internal and external service and process is highly understated in the archimate model, and think final model structure is remarkably close to a true logical representation of how many real organisations do business. In my short time in the enterprise architecture space, I have partaken in many discussions/arguments/debates as to what constitutes a ‘service’, ‘process’, etc that i think could have largely been avoided had we factored in types of the modelling artifacts based on the domain they are in.

    With the the current client, with highly siloed structures with poor cohesion, the above logical story whereby the organisation is a series of internal producers and consumers working in an macro-level process to deliver client I think delivers the right message in a clean format.

    Very valuable resource.


Leave a Reply to LOMBARDI BPM Cancel reply

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

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

Facebook photo

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

Connecting to %s

%d bloggers like this: