4

In the Archimate 3 Application Layer Metamodel there is no explicit realization relation between an "Application Component" and an "Application Service". However, in the example of section 12.3 there is such relation. How should I understand this?

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
nize
  • 1,012
  • 1
  • 11
  • 27

2 Answers2

1

Section 12.3 shows a derived relation implied from the metamodel so it is consistent.

Details: 1. The metamodel shows that a component can be assigned to a function which can realize a service. 2. Realization derive from (Assignation followed by Realization) 3. So a component can realize (derived) a service

Many (if not most) relations you will be using when working on real life examples will be derived, as you only want to show the concepts you are interested in.

l1b3rty
  • 3,333
  • 14
  • 32
  • 1
    Seems reasonable. Surprised I got a response on this in stackoverflow :). Other readers might be interested in the section discussing derivation: http://pubs.opengroup.org/architecture/archimate3-doc/chap05.html#_Toc451757969. Still I somewhat miss the notation used in UML in which you can explicitly state that the relation you have drawn is a derived one, by using a slash. – nize Dec 14 '16 at 10:38
  • In general derived relationships in ArchiMate are badly designed despite them being a must for impact analysis or to be able to create views customized to a given stakeholders. Next version 3.1 is supposed to fix this. – l1b3rty Dec 14 '16 at 10:47
  • Well I suffer from that my tooling doesn't support creating views presenting derived relations. What I mean is that I need to manually draw new relations between objects, instead of making the tool automatically view a derived relation. – nize Dec 14 '16 at 14:11
0

New Answer to an old question, but there is a set of rules to follow when deriving relationships, as noted in the ArchiMate 3.0 Specification:

The structural and dependency relationships can be ordered by ‘strength’. Structural relationships are ‘stronger’ than dependency relationships, and the relationships within these categories can also be ordered by strength:

• Influence (weakest)

• Access

• Serving

• Realization

• Assignment

• Aggregation

• Composition (strongest)

So for example if oyu have an application component and an application service, you have a an Assignement between the application function and the application component and a Realization between the application function and the application function.

So to take out the application function, you have to represent the relationship between the component and the service by the weakest, which is the Realization in this case.

Mart10
  • 758
  • 3
  • 14
  • You state there is a realization between the application function and the application function. It may be useful to edit or expand on this answer. – Lloyd Moore Sep 28 '18 at 13:18