Derived relationship between Node and Business Object

[bensopra]

Hi All,

I cannot understand why Archi is unable to set a derived assignment relationship from a Node to a Business Object as I'm able to design:

"Node" --assignment-->  "Artifact" --Realization--> "Business Object"

Thank you for feddback.

[Jean-Baptiste Sarrodie]

Hi,

I cannot understand why Archi is unable to set a derived assignment relationship from a Node to a Business Object as I'm able to design:

"Node" --assignment-->  "Artifact" --Realization--> "Business Object"

Simply because it is not allowed in ArchiMate :-)

See https://pubs.opengroup.org/architecture/archimate3-doc/apdxb.html#_Toc10045492 for detailed explanation of derivation rules, especially this:

For an element a and element b, if b is a passive structure element then only “access” or “assignment” can be derived from a to b

Realisation has a lesser weight than Assignment, thus a Realization should be derived but is forbiden by the previous rule.

Regards,

JB

[bensopra]

Thank you JB, I didn't know (remember?) this rule.

By this relationship:
"Node" --assignment-->  "Artifact" --Realization--> "Business Object"
I want to design that a DB server hosts data representing a business entity.

Do you agree with this design?

[Jean-Baptiste Sarrodie]

Hi,

By this relationship:
"Node" --assignment-->  "Artifact" --Realization--> "Business Object"
I want to design that a DB server hosts data representing a business entity.

Do you agree with this design?

As this can't be derived, I would suggest to instead use this construct: "Node" --access--> "Artifact" --realization--> "Business Object" which can be derived to: "Node" --access--> "Business Object".

Regards,

JB

PS: such questions related to ArchiMate and not Archi should better be posted to the ArchiMate User Community discussion board

[bensopra]

OK thank you.

[Phil Beauvoir]

Thanks for that explanation, JB. 

I was scratching my head wondering why this was so, until you pointed out the magical formula. Derivation rules are certainly not simple. It might be better if a similar question arises again to simply answer, "Because of ArchiMate magic!" 

[bensopra]

Another last thing JB, I'm very interested in understanding the underlying phylosophy of this kind of rule "exceptions".

Before I start a new thread on the appropriate discussion board, can you tell me if there is any online documention explaining "why" theses exceptions exist?

[Phil Beauvoir]

> Before I start a new thread on the appropriate discussion board

You probably already know, but the ArchiMate Community is probably the best place for this discussion:

https://community.opengroup.org/archimate-user-community/home

[Jean-Baptiste Sarrodie]

Hi,

Another last thing JB, I'm very interested in understanding the underlying phylosophy of this kind of rule "exceptions".

Before I start a new thread on the appropriate discussion board, can you tell me if there is any online documention explaining "why" theses exceptions exist?

The only documentation is the appendix B itself. Until ArchiMate 2.1, exceptions were not described at all, which led to numerous errors in the relationship table of ArchiMate 3.0 (fixed in 3.0.1 version). We since documented them, but you're right that the rational is missing. That could be a good addition for the next version of the standard.

The overall rational is to avoid non meaningful derived relationships. It is of known that a derived relationship is not always "right" in a user model, but some of them would be wrong or meaningless in all cases, and these exceptions try to avoid this.

Regards,

JB

[bensopra]

Thank you,

I created a new post on ArchiMate Community to go deeper in rationale considering my specific case:
https://community.opengroup.org/archimate-user-community/home/-/issues/21