Though I like ArchiMate, and I can (except for a few missing things such as Capability) model anything I encounter in the enterprise, I think some changes could make ArchiMate even more powerful. This is the first post in a small series.
Let’s start with the classic ArchiMate way of modeling two Actors performing some business behavior together, using the concepts of Collaboration and Interaction. An example is seen here:
In this example, our organization has a yearly process which is ‘Organize the yearly office party’, which by tradition is a collaboration of the Customer Support Department that handles logistics, like organize music, food and beverages. The whole publicity is done by the Sales Department. And this is a real collaboration, Support and Sales brainstorm together about the theme for the party, Sales advertises it and depending on the success rate of Sales, Support needs to buy different amounts of food, drink and beverages.
But what if we have the situation that each year either Sales or Support organizes the party?
The easiest way to model that is shown here:
It is unclear here, however, if they operate together on the office party, or that either one organizes it at a time. In fact, this pattern is generally taken as that both Actors fulfil the Role. And there is no way to show that difference in an ArchiMate structure (I can think of convoluted ways, but in the end they either depend on labeling, not on structure, or I have to make two Business Process elements, depending on who performs it, which makes my skin crawl).
But there is a change we could apply to ArchiMate that makes this problem go away (and opens many nice possibilities). We could allow Junction relations for more than just Triggers and Flows. In the next view I am using an OR-Junction to model that Sales or Support organizes the office party.
And in the next view I model, using an AND-Junction, that Sales together with Support organizes the office party.
And yes, this is in fact a simple way to model a collaboration — with four, instead of six, elements (not counting the Junction as a full element, but as a grammatical object that says something about the relations).
In the reality of an enterprise, almost all processes are collaborations/interactions (at a different scale). This is also why a specific Collaboration in the ArchiMate language is not really needed; in what I call the `informal collaboration’ multiple Roles are Assigned-To a single Process, and that is as expressive as with the special concept. Maybe the only aspect that would make it useful if it was to be used for a temporary collaboration. The question is, a Process is by definition temporary: it has a start and an end and you can have multiple instances of it side by side. And besides, if it is really temporary and not something that can potentially always happen in an enterprise, why model it?
As described in the Mastering ArchiMate book (Section 25 “Linking BPMN and ArchiMate” on page 156), using a typical EA-construct ‘named Collaboration’ is really impractical in many situations and also hard to get accepted by the business, who do not think in such structures when they describe business processes. There are, after all, many collaborations in the enterprise, many processes where people from various parts of the organization work together, but all these ‘collaborations’ are not recognized as a separate entity, bearing a separate name. Present them as such to the business, and they will feel that “the architects are making matters more complex than they are (again)”. But the use of a Junction to show that multiple roles together perform a process is perfectly acceptable to the business, it closely mimics how Lanes are generally used in (BPMN) flow charts..
There are many more ways in which using Junctions for the other relations are practical. One such an example is shown here:
Here, it is modeled that our (conceptual) Business Object ‘Bank Account’ is Realized by a Data Object of application A or a Data Object of application B. And that Data Object of application B is stored in the ‘[db001] Oracle Database’ or in the ‘[db002] PostgreSQL Database’. If we had a special symbol for XOR, we could also be specific about either/or.
By reusing (and expanding, e.g. include Specializations of Junction into AND, OR, XOR, maybe by adopting the Gateway patterns from BPMN) the Junction concept for all relations, we could significantly increase the power of ArchiMate and give the modelers the means to produce less ambiguous models.
Such models are more complex in their relations, so it is up to the enterprise architect only to model this additional clarity if it is useful. You do not need to do it, but the fact that you can allows for more clarity when required, e.g. for models that are used for analysis and reporting. Besides, it gives us an option to show collaborations in a way that fits business reality better (and simpler).
[A different wording of this proposal is part of the book Mastering ArchiMate – Edition II]
R&A IT Strategy & Architecture 
Funny you should bring this up. I was working through the options of Junctions in ArchiMate. Add a “type” attribute to the Junction concept. Tools can display AND/OR/XOR/whatever symbols as required. And also, as you say, change the ArchiMate relationship rules to allow more connections.
LikeLike
I suppose that the junctions should only join two identical types, i.e. two actors, two data objects etc. Whose responsibility is it, to ensure that this is so, is it up to the architect or should it be anchored in the syntax? Can you think of a situation where some leniency in type variation is allowed (for instance, a process is either assigned to a junction of a role XOR an actor; an application uses a file on filesystem OR a datastream output from another application)?
LikeLike