Missing relationships in Archi 4

[jbsarrodie]

Hi,

Original content:
It is not possible to create Access relationships from Behavior Technology Elements to Artifact...

JB

This entry is now used to track all issues related to relationship (i.e. relationships that should exist but are not in the official Appendix B)

• Behavior Technology Elements Accesses Artifact
• Artifact Realizes Data Object
• Actor/Role AssignedTo Work Package
• Actor/Role AssignedTo Implementation Event
• Implemetation Event flows/triggers Implementation Event
• Technology Process realizes Application Process
• Technology Process realizes Application Function
• Technology Function realizes Application Process
• Technology Function realizes Application Function
• Technology Interaction realizes Application Process
• Technology Interaction realizes Application Function
• Technology Interface realizes Application Interface

[jbsarrodie]

Answer to myself, in fact Archi 4 is really ArchiMate 3.0 compliant, even for its bugs...

The issue is that the official relationship table is missing the same relationship.

My 2 cts: we have to allow those access even if non standard or users will not be able to use Archi4 & ArchiMate3.

JB

[Phillipus]

What would be helpful would be to get a list of missing/incorrect relationships and then I/someone could edit the relationships.xml file.

[jbsarrodie]

@Phillipus I agree, let's log here all issues found. For each new one, I'll update the main content to have an easy to read list.

[pjjv]

Another one is:

• Actor/Role AssignedTo Implementation Event

BTW, many of these relations exists on Figures 77, 97 & 104, but missed in Appendix B tables

[jbsarrodie]

Good catch, I'm adding it to the list

[pjjv]

• Access/Specialization/Aggregation/Composition/Serving/Influence to/from Junction/OrJunction

[jbsarrodie]

Hi,

Re "Access/Specialization/Aggregation/Composition/Serving/Influence to/from Junction/OrJunction"...

No, those relationships are not allowed with a junction, as stated in the standard:
The relationships that can be used in combination with a junction are all the dynamic relationships, as well as assignment, realization, and association.

JB

[pjjv]

For access please check section 5.2.2, last paragraph before Example 7, on page 28:
If two passive structure elements are, for example, alternative information sources and only one of them is needed by the internal behavior element, an or junction (see Section 5.4.3) can be used.

For serving (paragraph before Example 6):
If two services are alternative solutions and only one of them is needed by the internal behavior element, an or junction (see Section 5.4.3) can be used.

[jbsarrodie]

@pjjv That's an inconsistency in the standard itself. It was not meant to be like that. That being said, we had some discussions on that topic inside the ArchiMate Forum and this might change with ArchiMate 3.1.

Regards,

JB

[pjjv]

Well, we do not have 3.1 yet ... and in both 2.1/3.0 it is permitted.

For me there is no big distinction between OrJunction on Flow and Access relation. Same holds for Serving/Realization distinction. So being curious about next update of the Standard with explanation.

But as (And)Junction is extremely useful graphical simplification of complex relations, it is nice that it is supported, even on those relations where OrJunction would not in next incarnation of the Standard.

[jbsarrodie]

in both 2.1/3.0 it is permitted.

Sorry, but it is not permitted in 2.1: junction can only be used with flow and trigger. And in 3.0 it was not meant to be used with anything other than flow, trigger, assignment, realization, and association (even if, I agree, this rule could be relaxed in upcomming version).

For me there is no big distinction between OrJunction on Flow and Access relation.

Access implies a data flow while a flow can be anything other than data (money, value, trust...) so even if it looks like the same it is not.

Same holds for Serving/Realization distinction.

Serving and Realization are not similar at all: serving means that you provide a service to something, but Realization means that you abstract something into a less tangible one.

But as (And)Junction is extremely useful graphical simplification of complex relations, it is nice that it is supported, even on those relations where OrJunction would not in next incarnation of the Standard.

Archi is meant to support the ArchiMate standard, not add anything on top of it, so junctions will be implemented strictly.

[Phillipus]

Hi,

just to confirm what JB says, we'll implement what is published in the ArchiMate spec as it is now to avoid confusion. If this changes in an update (2.1) we'll update Archi to reflect that.

Phil

[pjjv]

Phillipus,

I pointed that both Access and Serving Junctions ARE in ArchiMate 3.0 permitted with references to respective sections in the 3.0 Standard:

For access please check section 5.2.2, last paragraph before Example 7, on page 28:
If two passive structure elements are, for example, alternative information sources and only one of them is needed by the internal behavior element, an or junction (see Section 5.4.3) can be used.
For serving (paragraph before Example 6):
If two services are alternative solutions and only one of them is needed by the internal behavior element, an or junction (see Section 5.4.3) can be used.

So despite about informal discussion on some committee, Access and Serving junctions has to be supported now as they are in the 3.0 Standard.

For other usage of junctions, note that derivation rules apply, so try to derive on chain where one of the relations has OrJunction on it.

---

JB,

I know what is Flow and Serving, I meant that if:

• Flow has OrJunction specifying alternative flows (forks or merges), the underlying material or information flow can be specified by less abstract access permission, try to express OR without allowing OrJunction on Access relation
• Realization has OrJunction specifying alternative realizations, the Realization-Serving chain should follow the same principle with respect to derivation rules, otherwise we have an issue in derivation.

Ad Archi is meant to support the ArchiMate standard, not add anything on top of it, so junctions will be implemented strictly.:
Check the standard, how many times it said that (Or)Junction has no semantic interpretation, and how clearly e.g. section D.2 distinguishes ArchiMate junctions from BPMN's gateway semantics. I see no contradiction of my usage of (And)Junctions, especially as I use BPMN/UML when I need detail view on topic.

Personally, for me:

• I am only using OrJunction as meaning optional with single inflow and outflow (I know it is not Standard, but it is better accepted by stakeholders and it is supported by tools like Archi). Then Standard interpretation of OrJunction is combination of Junction and optional.
  In case of tools that enforce standard by permitting at least one multiflow side (in, out or both) on OrJunction, null element placeholder can be used in model, but not shown on diagram,

[jbsarrodie]

So despite about informal discussion on some committee, Access and Serving junctions has to be supported now as they are in the 3.0 Standard.

I was present during discussions about junction when we created ArchiMate 3.0 and I can say that those relationships are not permitted. The issue you pointed is due to an editorial error (the same remark has been added before each example despite not being relevant for some relationships). This has then been discussed and this will changed in ArchiMate 3.1 (in a way or another, not yet decided). So the official interpretation is: "The relationships that can be used in combination with a junction are all the dynamic relationships, as well as assignment, realization, and association."

For other usage of junctions, note that derivation rules apply, so try to derive on chain where one of the relations has OrJunction on it.
Realization has OrJunction specifying alternative realizations, the Realization-Serving chain should follow the same principle with respect to derivation rules, otherwise we have an issue in derivation.

Derivation rules are not intended to find relationships that exists, but relationship that might exist, so having a junction in the middle of a chain don't change anything, it only provide you two derived relationship instead of one (remember that a junction is not a relationship but an element -relationship connector-).

Flow has OrJunction specifying alternative flows (forks or merges), the underlying material or information flow can be specified by less abstract access permission, try to express OR without allowing OrJunction on Access relation

I don't see an issue as having a junction in the middle of a flow doesn't mean the information is different but only the origin (or target) internal behavior is, so when looking at the details, two access exists because each active structure accesses its data.

Archi is meant to support the ArchiMate standard, not add anything on top of it, so junctions will be implemented strictly

This simply means that only official relationships (those listed on the appendix tables and official definition of concepts) will be implemented. This is required to be sure that nobody creates an ArchiMate model that could not be imported in another tool (through the ArchiMate Exchange Format).

Personally, for me

Personally for me junction is not well defined in ArchiMate. If you really think about it, a junction is a way to put a constraint on several relationships, so I would suggest to make it a visual shortcut (like those defined for Communication Network and Path) for a constraint associated to relationships. This would have the advantage to be allowed for each and every relationships...

[pjjv]

To me this discussion only shows:

We have text full of relationships omitted from Appendix B, not mentioning those missed in the middle of the table in section B.1. This was start of this thread.

This simply means that only official relationships (those listed on the appendix tables and official definition of concepts) will be implemented. This is required to be sure that nobody creates an ArchiMate model that could not be imported in another tool (through the ArchiMate Exchange Format).

We have hard facts:

1. We have seen added text to Standard sections that is newly added to 3.0, pls compare to version 2.1.

This simply means that only official relationships (those listed on ... official definition of concepts) will be implemented.

2. We have ArchiMate Exchange Format (S161) XSD definitions, which permits these junction*relation combinations.

This is required to be sure that nobody creates an ArchiMate model that could not be imported in another tool (through the ArchiMate Exchange Format).

3. We do not have official OpenGroup errata published.

Ad Derivation rules:

1. A junction is used to explicitly express that several elements together participate in the relationship (and junction) or that one of the elements participates in the relationship (or junction).
2. If two structural or dependency relationships r:R and s:S are permitted between elements a, b, and c such that r(a,b) and s(b,c), then a structural relationship t:T is also permitted, with t(a,c) and type T being the weakest of R and S.

==> standard algebra distributive rules applies here between 1st and 2nd rule to be mathematically sound?

I was personally present during many standard & law creation process, all what counts, is the de iure text, with acompanying judicature (maybe meeting notes can enlight the intension), not what was discussed and maybe looks like typo to some members of the committee. Can we agree that Standard and ArchiMate Exchange Format (S161) are the only constraints we have now?
BTW, I saw presentations of some other members of the committee that shows junctions for Specialization relationship as well ...

[jbsarrodie]

To me this discussion only shows that you don't want to understand anything that I said, so this is going nowhere, sorry. And the fact that other members show non standard things just means that they prepared things in advance (ie. before standard was agreed) or that they use non standard tools.

[Phillipus]

Please note - the exchange format does not enforce any relationship rules.

[pjjv]

Phillipus,

yes, I know (read those XSDs before), but I did not introduced it as an argument.
I used it only to show its invalidity as a constraint. Others are Relationship Connector treated as an Element (in reality it is Concept only), ignoring of Derivation rules algebra etc.

---

JB,
the whole discussion shows that you do not want to accept Standard as a whole, including whole section 5.2, 5.4 and 5.6.

Serving, Accessing has written Junction example in Standard 3.0, not present in 2.1.

We can dispute if the paragraphs in section 5.2 or 5.4 are valid or not (similarly as we dispute validity of Appendix B/B.1). But please no more unofficial intensions from often dynamic standardization process at OpenGroup.

We can put it on hold until you during specification of derivation rules for Archi find that you need both Access and Serving to have junction permitted.

[mwherman2000]

Where is the relationship matrix stored in the Archi repo?

[pjjv]

If you mean repository - current beta has it in Archi\plugins\com.archimatetool.model_4.0.0.201612151122\model, where file relationhips.xml reside

[mwherman2000]

Thank you ...I also found them here (which I assume maps to the following location): https://github.com/archimatetool/archi/tree/master/com.archimatetool.model/model

[mwherman2000]

FYI: I've created a Neo4j graph database based on what is in the relationships.xml file. It's pretty interesting to query and visualize different parts of the relationship matrix. Here's an example.

The first thing that is obvious is the ArchiMate 3.0 spec should include some way to denote the "core" relationships - separate from all of the derived possibilities. The tables in Appendix B of the Spec (http://pubs.opengroup.org/architecture/archimate3-doc/apdxb.html#_Toc451758118) include some 11,000+ relationships for 61 entities ...a bit crazy.

TIP: Also note that if you open the relationships.xml in Excel, you get a nice 3-column spreadsheet (source, target, relations) that can be saved as a CSV file, for example.

Update

Checkout Crossing the EA Chasm: Graphitization of ArchiMate 3.0

[pjjv]

Another missing:

• Implemetation event flows/triggers Implementation event

[jbsarrodie]

@pjjv @mwherman2000

Good catch, I've added those issues to the list.

[pjjv]

Another set:
cf. section 12.2 last paragraph:

• Artifact realizes Business Object
• Artifact realizes Contract
• Technology Process realizes Business Process
• Technology Process realizes Business Function
• Technology Process realizes Business Interaction
• Technology Function realizes Business Process
• Technology Function realizes Business Function
• Technology Function realizes Business Interaction
• Technology Interaction realizes Business Process
• Technology Interaction realizes Business Function
• Technology Interaction realizes Business Interaction

[Phillipus]

@jbsarrodie When's the best time to make changes to relationships.xml? Do we need to make a definitive list and sign them off? Do we need to wait for update the written spec?

[jbsarrodie]

An errata should be published by The Open Group soon. During this activity a fixed table will be published.
IMHO, we should keep the beta until this fixed table is official inside the Archimate Forum, but release the next beta with a fixed (but unofficial) relationships.xml file.

[mwherman2000]

New: With respect to Technology Processes and Technology Functions, why does Archi not allow Access relationships from these to [Technology] Artifacts? This seems very odd.

[Phillipus]

If there are any missing relationships in Archi, it's simply because they are not in the relationship matrix in the official specification document so not enabled. It's easy enough to enable these relationships by editing an XML file, the only thing I need is agreement from users and the green light.

[mwherman2000]

;-)

[Phillipus]

:-) OK, we have a number of relationships that need to be green-lighted in this thread. I'm now wondering what's the best way to make a definitive list.

[mwherman2000]

I go along with jbsarrodie's idea that we wait a short but reasonable amount of time to see what The Open Group produces ...maybe a couple weeks ...maybe the end of February at the latest? ...or just build our own consensus and put Archi 4.0 out as the "people's standard" for ArchiMate.

[Phillipus]

OK, fair enough. As far as implementation goes, all it amounts to is simply editing the "relationships.xml" file and putting out a new build. I'm happy to do that at any time.

[jbsarrodie]

Hi Guys,

I think we'll not have to wait too long (end of feb seems achievable). What you have to understand is that for any of these missing relationships, there are many others that should have been derived and thus are missing too (but more difficult to pinpoint). So this is not straightforward.

In addition, there are also relationships allowed in the officiel table that should not even exist...

[Phillipus]

Thanks, JB.

What would be great would be a definitive matrix of direct relationships in addition to the derived ones. Would make it simpler for tools to implement.

[jbsarrodie]

@Phillipus :we're working on it :-)

[smileham]

Just wanted to update this bug with a number of issues post "beta 7" and Gerben's temporary update.

"Behaviour" Element flow/triggers Junction (and vice versa)
Plateau triggers Plateau #209

[adkendall]

Scanning through this thread and I see no mention of 'Deliverable Realizes Plateau' - which I think should be allowed (but isn't)

[pjjv]

Motivation elements shoud realize motivation elements, missing several relations from Figure 32

[Phillipus]

We are going to have an updated relationships matrix soon in Archi.

[mwherman2000]

Perfect for my iteration 3, I want to add .ArchiMate as well as the Exchange file format More specifically, I'll publish a model that has a view for each of the use cases in the white paper Your thoughts? Get Outlook for Android<https://aka.ms/ghei36> From: Phil Beauvoir Sent: Tuesday, April 11, 3:36 AM Subject: Re: [archimatetool/archi] Missing relationships in Archi 4 (#164) To: archimatetool/archi Cc: Michael Herman (Parallelspace), Mention We are going to have an updated relationships matrix soon in Archi. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#164 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AF0a6Ld3GAzLyt7aFaIepUnkSEPBzOf5ks5ru1fIgaJpZM4K4ebJ>.

[Phillipus]

Sounds good to me!

[gabga]

Representation realizes business object is missing.

[jyl13]

i have the feeling lot of relationship have been lost since 4.0.0 beta4 When I compare relationships.xml between 4.0.0 beta4 and 4.0.0 pr1 there are a lot of mismatches some are probably correction but other sounds to be new 'error' for example relation between path and application component are 'o' only 4.0.0 pr1, while there where 'fot' and 'fortv' in beta 4.
Here below copare of both section in 'source concept="Path"'

[Phillipus]

There will be even more changes to the relationships very soon in Archi 4 PR2. We will be using the corrected relationships rules. The matrix in the 3.0 spec document is incorrect.

[roelm]

The help section concerning relationships refers to the Archimate 2.1 specification:

[Phillipus]

The help section concerning relationships refers to the Archimate 2.1 specification

I've updated the screenshot for next build.

[Phillipus]

The relationship rules in Archi 4 PR3 have been put together by Ed Roberts of Elparazim. See http://www.elparazim.com/blog-post/deriving-archimate-3-0-relationships/

From now on, if there are any changes to the relationships rules they will have to be in a format that I can easily consume in order to edit the relationships.xml file. And agreed by all.

[Phillipus]

As things have moved on since this was opened, please continue in #243