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…
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
I think you show more and more with these articles that Archimate reflects mainframe era computing where the interaction between human and computers is very discrete and clearly defined. And the underlying processes are simple sand block-like.
I agree that ArchiMate shows some outdated history in its fundamentals (we’ve moved on), but I don’t think it is ‘mainframe area’. I’ve led an initiative to fully model a Business-IT landscape (and use it for project architectures) where there was no mainframe anywhere among the 41,000 elements and relations. But I agree that it echoes a more simple past.
Where ArchiMate could grow would be the power to describe volatile landscapes (think DevOps) and infrastructure (here ArchiMate shows a dim past when infrastructure people were not really allowed at the architect’s table…
I don’t want to enter into a discussion on specific concepts here (I could counter your arguments, but I won’t). We are currently in the process of revising the standard and some of the concepts you mention will get an improved definition, metamodel restrictions may be relaxed, etc. I cannot go into the details, since it is up to the ArchiMate Forum to decide on that. One thing I do need to say is that we cannot simply drop a concept from one version of the standard to the next, for reasons of backwards compatibility. The first step would be to deprecate a concept and mark it for possible removal in the future.
I could live with depreciation of Interaction as a first step and, as I wrote, I have no problem with keeping Collaboration in a less strict role for those who like to use it explicitly.
Hi Marc, I’ve been thinking about your post for a few days days and I have to say it’s both disrespectful and intellectually dishonest. Not being able to discuss the matter is one thing but the little boast that you can counter Gerben’s points but you won’t is disrespectful not just to him but too the entire Archimate using community.
Robert, thanks a lot for your public insult. I was merely stating the obvious: there are clear reasons why interaction and collaboration have been included in ArchiMate, but I won’t repeat those here and I cannot enter into a discussion on ArchiMate’s next version since that is for the ArchiMate Forum to decide.
As i stated Marc I have no issue with you not discussing what the forum is working on, that’s to be expected, but you did more than state the obvious. I quote “I could counter your arguments, but I won’t”. We may be having a difference in English idiom, but to me as a native English speaker that implies contempt for the other person.
Gerben plays a significant role in helping people understand Archimate both here and on forums like LinkedIn and deserves to be treated with respect.
For the record: I do not feel disrespected by Marc if he states “I could counter your arguments, but I won’t”. I’d prefer that we keep our eye on the ball (ArchiMate) instead of the players. Having said that, I agree it is a ‘zwaktebod’ (Dutch idiom for weak argument/weak play) but I don’t feel disrespected by that. I’d be very interested in actual counter arguments, of course and it’s sad that they are not given. Marc would be welcome to publish a full guest blog post here (not just a comment) to counter the arguments.
Thanks Gerben. It seems to be a common situation (in my country at least) that you get a job (or contract) and you immediately find yourself having to defend the value of architecture. I think that ISO/IEC/IEEE 42010 gives us a good basis for articulating what architecture is, but we need robust and rich descriptive methods for communicating with our clients. My fear is that Archimate is in fact captured by commercial interests and is really a distraction.
I won’t remove posts, but I would ask every poster to stay far from anything that can possibly be considered impolite as well as assume beforehand that others are not out to get you. All in accordance with the Robustness Principle: Be conservative in what you do, be liberal in what you accept from others (often reworded as “Be conservative in what you send, be liberal in what you accept”). https://en.wikipedia.org/wiki/Robustness_principle
Thanks Gerben, I value your contributions and respect your position. I don’t want to argue with that although my position is different, because of the reasons stated. I could explain the reasons for having both concepts privately to you, but since I lead the ArchiMate core team developing the next version of the standard, I don’t want (at least in in this stage of the process) enter into a public discussion on its evolution.
Isn’t there old material that explains the ArchiMate pre-1, 1 or 2 situation? That would not breach any current discussions going on.
Yes, there is, but since the demise of Novay the original ArchiMate deliverables are no longer available online, and strictly speaking they are owned by The Open Group since the transfer of the standard to them. Some of the reasoning can also be found in the Enterprise Architecture at Work book.
To use abstract concepts (such as collaboration and interaction) as the underlying reality is getting more complex (eg. increasingly collaboration through networking), you pay a higher price by missing more and more details. Gerben’s proposal sounds sensible to me, but I am also curious in what way the next version of the standard will make ‘collaboration’ and ‘interaction’ more useful.