[Feature Request] Showing implicit relations

[trond-eirik]

I really would like to see a option to show implicit relations. For example, say that I create a full and detaljed model that shows an application componenents. The application component has a interface. A correct way of modelling this in Archimate is to model that the ApplicationComponent has a application function. The function realizes a application service that is assigned to a application interface. However, in another figure I want to simplifiy this and I do not want or need the internal fuction or the interface, so I just want to show that the application component realized the application servcie. I would like archi to calculate that there is a connection and show it. Archi should only show the strongest connection between the two points. Maybe the connection should be shown in a gray array.

For a user this could be solved so that you can select two objects, right click and select "Show derivided connections"

If possible - the best is that the Archimate specification is used to define what connections to show. If the Archimate spesification is not detailed enought - or if there is not way to select a given type of array - maybe archi should just do a fallback to the general "association" connection.

Full archimate model: Implicit relation: Implicit relation:

[jbsarrodie]

Hi,

Some remarks (related to Archi or ArchiMate)

A correct way of modelling this in Archimate is to model that the ApplicationComponent has a application function. The function realizes a application service [...] However, in another figure I want to simplifiy this and I do not want or need the internal fuction or the interface, so I just want to show that the application component realized the application servcie.

In fact we should not say that it's the "correct way". Nothing In ArchiMate says that you have to model at a specific level of detail and use the whole pattern that is shown in metamodel snippets of a layer. It all depends on usage and need, so if in your model you don't need both level of detail then you can simply model the Application Component that realises the Application Service.

I would like archi to calculate that there is a connection and show it. Archi should only show the strongest connection between the two points. Maybe the connection should be shown in a gray array. For a user this could be solved so that you can select two objects, right click and select "Show derivided connections"

This used to exist in Archi before but was dropped in Archi 4.0 because derivations rules was new but known to be changed (this is expected in upcoming new version of ArchiMate). We should at some point add it back, but this involves more computations than before as rules are now more complex. In addition depending on usage some rules makes sens and other don't, so we might end up adding this as a jArchi script instead of a fully integrated Archi feature.

the best is that the Archimate specification is used to define what connections to show

Well, not really. ArchiMate provide you some potentially meaningful derived relationships, but this always has to be challenged by the one who creates the model.

This realization is not derivable. Either you derive a serving or you replace your business service by the application service.

Regards,

JB

[trond-eirik]

I agree about everything you said. Lets focus on this: "We should at some point add it back" It would be great if that point was as soon as possible - for me at last it would add huge value to the usage of Archi. And that would probably make it much easier to avoid errors like then one above, where there should have been a serving relation while I used a realizing relation.

[jbsarrodie]

It would be great if that point was as soon as possible - for me at last it would add huge value to the usage of Archi.

Archi being opensource, don't hesitate to contribute to this feature or to sketch a jArchi script for that ;-)

[Phillipus]

Does there exist a definitive list of core and derived ArchiMate relationships in machine readable form? That would be a start.

[trond-eirik]

I do not have any define list, but I did find that the Archimate-specification chapter 5.6 defines Derivation Rules. http://pubs.opengroup.org/architecture/archimate3-doc/chap05.html

[jbsarrodie]

Does there exist a definitive list of core and derived ArchiMate relationships in machine readable form? That would be a start.

Such list exists inside The Open Group and can be communicated. But I would not call this a start as we have in fact two very different things:

• We have relationships that are listed in Appendix B of the standard and are derived from ArchiMate metamodel (which contains 'core' relationships). I'll call this metamodel derived relationship. This is mainly useful for people who work on the standard, not with the standard. People can use such relationship directly if they don't need to model in too much details
• We have relationships that are derived from other relationships (metamodel derived or core) that have been previously added to the model by someone. The typical use-case is to model something at several levels of detail/abstraction.

The "definitive list" we're talking about would only help to identify metamodel derived relationships, but what people mostly need is a way to "link"several relationships that express the same thing at different level of detail/abstraction. Being able to do that would help because a change at one level of detail/abstraction would raise a warning to guide user to update other levels.

[trond-eirik]

About the solution for this. It was mentioned that this was supported in a Archi 4 - but removed. Does this mean that a solution for how to do this is already designet, and that the only thing missing is a set of rules about what relations to show when?

[jbsarrodie]

There used to be a feature that was allowing you to select to elements in a view and ask (through context menu) to look for derived relationship. Then the Archimate 2.x derivation rule for structural relationships was applied and potential relationships was prompted to the user for him to select (or cancel). If selected, the derived relationship was then created and kept in a "Derived Relationships" root folder inside the model.

But...

• This was working only for structural relationships and not dynamic relationship (different rule)
• After creation, there were no relation between the derived relationship and the relationships used for its creation, meaning that one could remove a relationship without being warned that this had an impact.
• In fact, this was almost never used by users.

So we decided to not implement it again in Archi 4, but instead wait for:

• The Open Group to deliver a new set of derivation rules (should be published early next year)
• People to define a better use-case that really creates value for user

[trond-eirik]

Regarding: People to define a better use-case that really create value for user Is that point archived or do you need more documentation or what? (as I feel I have a pritty clear use-case)

[jbsarrodie]

Is that point archived

For the moment I only have my use-case (which matches use-cases from colleagues too).

as I feel I have a pritty clear use-case

Share it here, that's a good place for that.

[kaiserghetto]

This realization is not derivable. Either you derive a serving or you replace your business service by the application service.

HA! I learned this today. The derived relation between both ends of the route is the weakest relation found on the route.

[trond-eirik]

Use case: As a architect I have created multiple architecure views of several applications - each one fairly detailed (as I have used the design to understand and verify with the developers). Now I have to create overview models for other stakeholders. (Basicly what is shown in the i initial post if you just replace realized by with serving)

Functional I would like to select several objects and have a context menu with «Show derivided relations» or something like that.

[MilennialZero]

I spoke to Marc Lankhorst by email a few years ago and asked about the derived relationship thing. The Archimate specification is open to interpretation by vendors. I realised derived relationships doesn't really work the way I'd want, or expect. It was intended to trace relationships in a direct upward linear path. It loses sight if paths proliferate and go sideways. The specification isn't explicitly clear to vendors as to how to implement. "Big end of town" tool / repository vendors already implement something better than Archimate derived relationships. Orbus iServer, Unicom System Architect, etc. Out of reach for Archi. I think the value of derived relationships is to enable us to give us flexibility to model and "leave things out". We're not forced by the language to model all the intermediate concepts and relationships if we want to show a relationship between a business service and a technology node with system software on it, for instance. My understanding, anyway. Happy to be corrected by others in possession of alternative facts.

[jbsarrodie]

I think the value of derived relationships is to enable us to give us flexibility to model and "leave things out". We're not forced by the language to model all the intermediate concepts and relationships if we want to show a relationship between a business service and a technology node with system software on it, for instance.

Yes, that's the whole point. We (The Open Group ArchiMate Forum) are making it a bit clearer for the next version of the standard. That's also why Marc (and I fully agree with him) says that derived relationships are first class citizen in ArchiMate and most of the time users should not bother too much about them.

We then have IMHO two different use cases:

• Find derived relationship from existing relationships in your model to do impact analysis or equivalent. My feeling here is that we almost always have to introduce context specific rules. It then become impossible for a tool to directly support this use-case, but it can indirectly through scripting (more than half of the script I create for me or clients match this use-case).
• Find derived relationship from existing relationships in your model to create view at a more abstract level. This use-case is comes with another requirement that people often forget: tool must be able to "relates" those derived relationships to their "constituent" or else, whenever we change the detailed views, we'll be left alone to update the abstract ones. Here is the value for a tool, IMHO.

[trond-eirik]

The sexond case - what happens when you update your detailed views are important. However - I’m a bit afraid that if we add to mutch requirements the solution might be so hard to implement that nothing will be made. In that case I would rather have a imperfect solution that gets me a part of the way than no solution.

I think the already thought up solution seems like a good one. Maybe if it is possible to have functions for a diagram that:

• shown/import existing relationship beteeen selected items (both regular and derivided)
• generate derivided relationship between selected items
• let you select all derivided relationship (and thus make it easy delete them from either the view or the model)

You say that derivated relationship are first class citizen - and I agree about that. But that also come with a backside because it means that if you draw out all derivided relations you get extremely many relations - and when you for example starts to add elements to a drawing you will always delete a lot of relations that are actually derivided relations.

Treating derivided relationships as first class citizen means (for me) that tools should support generating them both after that not handle them specially. Given that approach the tool should not need to mark a derivited (and generated) relationship different than other relationships.

And that is a point as I may create derivided relationships both manually and by using a tool. I might as well start with an overview diagram and then create more detailed diagrams (and in this case I actually create the derivided relationships first).

Based on this I think that a solution for derivided relationships should ideally be able to analyze the model and decide if any relationship is a direct or derivided relationship. At the same time the tool should be able to always show any derivided relations. This making any derivided relationship a virtual relation that «pops into existance» or «vanishes out of existence» based on the other relations in the model.

I do kindof have some loose idea about how this could work but I’m not able to define any rules and it migjt be that it will not be possible to make a solution that work like this and at the same time does not confice the user - or messes up the users work.

My key point is that there is not any actual difference between anindirect relatipnship created by the user and one created by the tool - and the solution should if possible be designed with this in mind.

[achampion]

Testing my understanding of derivation rules... App Component - realizes - Business Service can be derived via App Component - assignment - App Process - realizes - Business Process - realizes Business Service. Which derives to realizes as it is weaker than assignment. However it might not mean what was expected as it describes a Business Service that is fully automated.

[peteraritchie]

Jumping in very late... I used the derivation feature quite a lot. One for better understanding of Archimate; but two to make relationships explicit so that there were conventions to suggest a better way, it would be visible.

[jbsarrodie]

@peteraritchie

but two to make relationships explicit

I'm not sure to understand you (in the context of this issue).

There's noting in Archi stopping you to add derived relationships. You simply have to create them yourself and not rely on a tool to compute them (which in the end means that you have to choose the right one in your context anyway).

[lvmm]

That's exactly the point: when you create new relations you end up with two (or more) sets of relations for what logically is the same relation, and create a mess. It would be nice if Archi allowed relations terminating on nested components in one view to be used for outer components in another view and vice versa, e.g. consider a typical MSA application: on the top-level view relations terminate on services, on detailed views the same relations terminate on interfaces nested inside these services which are not shown on the top-level view for brevity. But they are the same relations and should not be duplicated unnecessarily.

[joshliberty]

I’d just like to add that this is one of the features I almost expected Archi to have when I started using it, and was quite surprised that it didn’t (I don’t mean this in a snidely way at all - I realise how difficult and problematic it can be).

It feels to me like a hugely beneficial feature - when I create a detailed model, it would be extremely useful to (semi) automatically generate a simplified version of it (where I choose a selection of elements and the most suitable relations are added automatically).

Since this issue is open 4 years - has there been any update on this? Is it a planned feature or was it dropped completely?

I might try my hand at creating a jArchi script for it.

[nickbrownapollo]

I know this is an old thread, but I'd like to see some support for derived relationships. Personally, I could live without any in-built logic and would happily create them myself. But I'd like for them to have a property that identifies them as derived and for Archi to make use of this property to distinguish them where appropriate - the visualiser, default view settings, Analysis/model relations list for example. I'm currently using my own property value to flag derived relationships, but that's mostly for my own info.

[ainthek]

Please any update on this issue ? summary ? thanx

[Phillipus]

Please any update on this issue ? summary ? thanx

Nope. thanx