Open Letter to TOG #2

Dear TOG,

I hope this letter finds you well.

As shepherd of the ArchiMate standard, you are currently working on its next iteration. As I am not part of the ArchiMate Forum, I am going to send you a few open letters with suggestions for improvement of the language and what to do an not to do. I will be voicing some stern/harsh criticisms on ArchiMate in these letters, please don’t take it personal, I’m only interested in strengthening the language which I already find useful as it is. And I apologise beforehand for my language here and there.

This is the second of such a letter.

Today, I want to write to you about Collaborations and Interactions

I ended my previous letter with a famous quote from Sidney J. Harris:

In every field of inquiry, it is true that all things should be made as simple as possible — but no simpler. (And for every problem that is muddled by over-complexity, a dozen are muddled by over-simplifying).

I used that quote in order to strengthen an argument for some extra features in ArchiMate. Don’t worry, I’m not planning to create ever more complexity in ArchiMate, even if ArchiMate is going to have to survive in ever more complex Business-IT landscapes. In fact, today I’m going to suggest a simplification in ArchiMate, I’m going to argue that we can drop Interactions from the standard ArchiMate metamodel and possibly Collaborations too (though they could stay as a useful specialisation for a few cases).

ArchiMate says about Collaboration and Interaction in general:

A collaboration is defined as a (temporary) grouping (or aggregation) of two or more structure elements, working together to perform some collective behavior. This collective behavior can be modeled as an interaction.

In two of the three layers (business and application) this setup is implemented. In the business layer, the Business Collaboration is an Aggregation of Business Roles which is Assigned to Business Interaction as its behaviour. In the application layer, the Application Collaboration is an Aggregation of Application Components which is Assigned to Application Interaction as its behaviour. Furthermore, Business Collaboration is a Specialisation of Business Role in the metamodel and Application Collaboration is a Specialisation of Application Component in the metamodel. See the previous letter for more about these ‘Specialisations’ in ArchiMate and the confusion that surrounds them.

When I was developing an BPMN-ArchiMate linkage (in collaboration with Dick Quartel, for the initial notes see here, and here, and for the final solution I came up with see the chapter in Mastering ArchiMate Edition II) I noticed that many (if not most) of my organisation’s real processes (the ones recognised and documented as such by the business, the ones reported to regulators, etc.) are in fact collaborations between multiple roles. And it was not always some roles that could be simply Aggregated or Composited in a higher-lever role. E.g., the legal department may have a role in the creation of deals with counter-parties by the sales department. Or for some large deals, suddenly the board gets involved to review and OK the deal. Or the sales process requires at some point the input from the finance department.

Here is an extremely simplified version of how real processes look in organisations:

Such a description could for instance be sent to regulators of your industry. Again, this is extremely simplified. But the idea is that a request for an offer is handled by a Sales Employee (Business Role), that the final offer is checked by the Company Lawyer (Business Role) and that for deals over 500k the full Board of the company must decide. The reality of such processes is that they are far more complex, but the example here can be used to show that what is seen by the organisation as a single process, almost always is a collaboration of many different roles, often across the organisation. Also, many important processes have all sorts of checks and balances and these actually require a clear separation of roles performing a part in that process. If you look at the real organisation you will find almost exclusively collaboration between roles to perform processes.

ArchiMate says about Business Process:

A business process describes the internal behavior performed by a business role that is required to produce a set of products and services.

This is meant as the behaviour of a single role. The standard says:

In comparison to a business interaction, in which a collaboration of two or more business roles are (interactively) involved, at a given level of granularity only one business role is involved with a business process. However, a complex business process may be an aggregation of other, finer-grained processes, each of which may be assigned to finer-grained roles that are aggregated by roles that are aggregated by the original role.

Internal behaviour of a Business Role? As far as I’m concerned, ArchiMate’s idea about processes is rather academic/utopian and it does not survive a confrontation with a real organisation at all. As soon as you try to fully model your organisation it the way ArchiMate says you must, you will end up with one big Business Role that performs every real Business Process in your company.

When trying to match processes in BPMN to ArchiMate I thus ran into the following problem: Technically, ArchiMate says that if I have multiple Business Roles together executing a Business Process, I should use Business Collaboration and Business Interaction. But that came with two disadvantages:

• Most to-be-documented-or-designed processes would be modelled as Business Interactions, but the business looks at these as Business Processes. In fact, the idea that a Business Process should be executed by a single Business Role is a constraint that nobody in the business understands. For them (and for me) most processes are in fact some sort of collaborative effort of multiple roles as shown above.
• Every different combination of Business Roles that would perform a Business Process (technically: Business Interaction) would become a separate Business Collaboration in my models, with a separate existence as a named element in the model, and most of them would only exist for performing a single Business Process. Besides, I wanted some sort of automated or semi-automated link between my processes modelled in BPMN and my processes as shown in my ArchiMate EA models. A simple but killing question became: how do we name each de facto Collaboration that in that case comes out of the process descriptions in BPMN? I am completely losing my audience (the rest of the company) if every combination of roles that happens to execute one of the hundreds of processes suddenly becomes a named ‘Collaboration’ entity. Too complex and convoluted by far.

So, while in a few cases it might be useful to model a specific Collaboration to draw attention to it (e.g. see the previous letter), in most cases, collaborations in an organisation are nothing special, but something that happens all the time. And whatever the behaviour, it can be either a collectively performed process or a function. There is no need to have this extra behaviour type ‘interaction’. Whatever the interaction you want to model, they would either fit the process concept or the function concept. Interaction is superfluous. The process shown above is performed by multiple roles, and it is simply a ‘process’, not something more complicated.

Anyway, the solution is pretty simple. Instead of using the idea that you can divide the processes of the organisation up in a tree-fashion, all the time getting more fine-grained in your description (which is just simply false if you look at real processes of real organisations, it is not a tree it is a web), it is better to accept the actual  m:n relation between roles on the one hand and behaviour on the other. So, we would not be surprised to see the following:

Which is much simpler and says exactly as much as the whole setup with Collaboration and Interaction. It even opens the road to some more interesting possibilities (maybe in a next letter).

In summary: collaboration is already covered by the structure of the language (multiple assignments to single behaviour) and does not require a separate concept. The idea is probably based on the mistaken assumption that you can create a ‘tree-of-granularity’ when creating a model that has processes and roles. You might keep collaboration where you want to stress it for some reason (e.g. when you are collaborating with someone outside of your organisation). For the rest, Interaction is completely superfluous and only muddles the picture.

And don’t get me started on what Collaboration and Interaction actually have to mean in the application layer. For that, read Section 8.1 of Mastering ArchiMate Edition II…

Yours truly,

Gerben Wierda

Team Coordinator Architecture & Design at the All Pension Group (APG)
Former Lead Architect of APG Asset Management and of the Dutch Judiciary
Author of Mastering ArchiMate and Chess and the Art of Enterprise Architecture