Shouldn't this be moved to per relationship sections for the sake of readability? If not, I suggest to reformulate as saying that the uniting concept is ALWAYS an element and then providing two exceptions (over 3 relationships), is a bit odd. (JB)

Fix reference to Common Domain chapter (JB)

No more true. Should be removed (JB)

Name of the grouping should be at the top of the element, otherwise it seems to be the name of the relationship.

I would maybe add the third which is the structuring of a diagram to become more easily readable.

I don't remember a CR to change the box notation's outline from dotted to solid. And examples still use the dotted outline. Do we want to change it ? (JB)

Update: Grouping represents.....

Should be moved at the beginning of the "4.2.4 Event" section (JB)

I find it hard to relate this sentence with the one starting with "it does not , however...". maybe replacing the dot by a colon? (JB)

Roles assignment refers to subprocesses but the assignment of the role to the whole process should be defined prior this statement.

Shouldn't this paragraphs moved after the "4.2.2. Process" header ? (JB)

Misprint: "clearly" (JB)

Simplify by removing "an external behavior element, called", to keep only a definition starting with "A service represents..." (JB)

Not only node, but any active structure element. The meaning of this aggregation should be better explained. (JB)

Proposal: "A path can aggregate internal active structure elements to model the people and technology on which the path relies"

I would change "it is" to "it may be" If we use path to express communication among people then it will not be realized by neither of them.

We should add back a note saying "In this and other metamodel figures, the label of a relationship signifies the role of the source element in the relationship; e.g., a service serves an internal behavior element." (JB)

"also" should be removed as it suggests that the previous text about color is also part of the "standard notation". (JB)

Unwanted opening bracket "[" (JB)

Maybe the whole paragraph should be moved to chapter 5 (Relationships) (JB)

Not true for specialization where the outer element is the target one.

That's the opposite for specialization (JB)

5.2.2 still allow nesting for access, and I personally think it makes sense because this is another meaning than the newly added assignments to passive structure. (JB)

It seems there is an unwanted closing parenthesis ")" (JB)

It seems there is an unwanted opening bracket "[" (JB)

No more true (JB)

The word unit is a bit confusing. As the process may be divided into fin-grained processes while the word unit may be impoperly understood as something that cannot be split into pieces.

Almost anything can perform behaviour, e.g. paper can burn, stone can melt etc. Should we somehow reflect that in the description? I usually use the explanation that passive element is something we manipulate with but not sure if it fits better.

can be accessed or manipulated by behavior elements (AP)

inconsistency between the way how interface and service are described. Either both should be white with name in brackets or both should be grey.

There is no more such explanation in "Common Domain" (or it as best incomplete). We might want to add back this previously existing note in "Common Domain" (and btw fix the reference): "In this and other metamodel figures, the label of a relationship signifies the role of the source element in the relationship; e.g., a service serves an internal behavior element." (JB)

no comma here (AP)

Model i a collection of concepts across multiple domains, I thin concepts should be used here.

combination with elements from other domains (AP)

with elements for modeling (AP)

contains elements to model (AP)

generic elements (AP)

combine elements from one or more aspects (AP)

Shouldn't this link be added to the "Referenced Documents" instead of being only here ? (JB)

I think we should change the (original) definition. A Domain doesn't look like an abstraction to me. (JB)

Junction is also defined in Chapter 5 (different wording btw). Maybe we should remove it from Chapter 2. (JB)

Misprint: Technology (JB)

I would add "and domains"

Inconsistent way of referencing the domains compared to other statements (e.g. 2.2.)

Fix reference to Common Domain chapter (JB)

Fix reference to Common Domain chapter (JB)

Fix reference to Common Domain chapter (JB)

Should be "Common Domain" instead of "generic metamodel" (JB)

I woul change for concepts as the mechanism should apply to relationships too.

We have to update this part to reflect the involvement of every member of the Coronado workgroup (JB)

Fix reference to Common Domain chapter (JB)

Not true for NEXT version, was valid for minor versions (e.g. 3.2)

I think that it should be replaced by (specialization) of business object, not a data object. The rest remains.

Inconsistent junction naming compared to chapter 5.5.

According to my experience most of the customers use different icons and colour for specialization which might be reflected in the picture. As I remember it was in 3.1 or previous. versions e.g. https://pubs.opengroup.org/architecture/archimate2-doc/chap09.html#_Toc371945251

I would also add negatives: Limited understandability by other parties like partners, suppliers and even readers within the organization who learnt standard ArchiMate.

Too specific.

This is tool specific. I would not prescribe how to implement the specialization.

Too specific, standard should not prescribe.

Almost the same statement as the first sentence in the previous paragraph

The word application might be confusing for non-native speakers as they would think it somehow relates to application domain. I would rephrase it or remove the word application here.

This picture still uses layers, Domains should be used instead

The bottom two are not properly horizontally aligned so the link is not narrow

The ISO standard specifies that Viewpoint and View have 1:1 relationship which is not true in general and also not true for ArchiMate. You can have multiple views (ASIS, TOBE) governed by one viewpoint. Do we want to address it at least by mentioning it?

I would be precise to say it is Plateau composite element.

I would add explanation what does it means. I am personally confused by the aggregation realization here. In most cases I think people would like o express that some goal will be realized by some plateau. Using aggregation means something different - possibly that the goal is valid for only that time period but not necesarilly realized by that. On the other hand it would mean that aggregation is weaker then realization in this case.

I think Plateau may also aggregate Grouping, it should be stated in the right top box. The picture is also cropped on the right side.

I would not start explaining Plateau by referring to TOGAF. It is needed regardless what TOGAF says and is valid for other methods as well. More generic description is needed first (at least switch order with the second paragraph).

In all previous chapters description of an element always ends with its notation picture. In this chapter some texts are present below the notation picture so it is inconsistent to the rest of the document

I think there is a general inconsistency in the allowed relationships for example: If an Application component may be realized by a Device, then a Service realized by the Device (e.g. Hosting Services) whould be allowed to realize the same Application Component. Otherwise we loose the strenght in the derivation here. My proposal is not to allow it but to restrict the realization from Device to Application Component (and similar realizations).

Improper order of the elements, active should be left, passive right.

Possibly missing relationship between Application hosting service and Financial Application Web Archive artifact - inconsistent with the other technology service which accesses the other artifact.

It is but is not present on the picture and is stated as a last sentence in the chapter. I would either explicitly show this on the picture or state it already at the beginning.

I would not put Application component between Facility and Business actor. It is hard to read and people may think there is some link between Application Component and Business Actor. Please split these into separate columns.

Too historical, it is not a primary goal of today's EA as I understand it. I would simply remove or rephrase this sentence.

It can also represent something that is not a file like packet or message or emails sent via network. How to name such things?

I would also add: "and equipment may be assigned to material, modeling the storage of the material within that equipment."

The icon notation differs from the boxed icon notation. The icon notation should be changed

The icon in the box seems to be improperly scaled compared to icon itself.

Propoisng attributes is too detailed, see my previous proposel to put all the proposed attributes to an appendix.

I like the definition but not sure of to refer to TRM which is in my opinion dead for already for more then 10 years ... It may cause that ArchiMate will be perceived the same.

The icon chimney is somewhat broken

Aggregation to location applies to all the elements and should be either listed in every element description or at none. How to work with locations is described in 4.3.2 and I think no more details are needed in later chapters.

Please add a short description in chapter below explaining the use of livestock e.g. Equipment may also be used to describe animals, especially livestock to express how it consumes and produces materials (hay, milk, manure) or otherwise manipulates with material (horses pulling wood elephants carrying tourists).

I would also add some open places like parking place, airport , port or mine.

Not needed here as it is also not stated at the other elements.

I would put this UML related text as the last sentence in this chapter not the second.

Not only application components as it is stated in the end of 9.2. I would rephrase it to either remove the application component reference or refer to other potential consumers.

excluding services? Application service is also a behaviour of the application.

Most of it is already part of the definition.

and Common Active Structure Elements (Roles and Collaborations)

This chapter uses statements like you can which is the other style than the one used in previous chapters.

I would replace influences by realizations to describe the structural view on how the motivation will be achieved. Wrong location colour.

While the statement is completely true I would think of updating the statement as somebody decided to create an exam question on this very detail.

Icon notation scaled differently than the icon in boxed notation

Another case for previously discussed grouping meaning

The sentence should possibly continue and not to be split into two.

I would rephrase it to Example capabilities names are ... Or remove it completely as there are examples just before the notation overview

It is already stated on the picture so it is not Additionally... Or it should be moved above the picture.

Maybe it should be mentioned, that relationships to Implementation and Migration elements are described in their chapter and not here.

Inconsistently scaled, should all have the same size

I would add somewhere in the chapter that the value can be positive and negative.

Mixing realizations with influences in this picture is not a good approach. Either we want to show how things are realized or influenced. In this picture the realization vertical is broken by influences and is unclear, how the goal will be realized.

Should we state here that they should be S.M.A.R.T.?

For me it is too much SWOT oriented but also other techniques may be used to assess something. I would rephrase it at least by saying that it is one of the common approaches, examples etc.

This and following pictures are improperly scaled and do not keep the aspect ration

I think listing the elements in the text does not bring any value.

Please switch the order to active - passive (left to right)

Inconsistent sizes of arrows, lengths and line widths for some relationships

See my comment on junctions to split them into two separate concepts.

Does it mean we predefine some attribute (profile) with specified values for it? Is it mandatory for tools and will it be part of exchange file? Or is it just an example how to do it and left to the modeller?

For me role is missleading here as it may be understood as referring to Role element.

Ca also junction have a name? I expect so.

or both as it is not an exclusive or (XOR). But for simplicity I would keep it as it is.

I think we agreed on spliting the junction into two separate concepts And junction (without brackets) and or junction. Currently it is unclear if it is one concept or two. regardless of the result of splitting it I would really remove those brackets for And.

Which is against what chapter 3.7 says (already commented on that).

Inconsistently bigger (and shorter) compared to other relationship notations.

I would mention that junctions may be used here to express the same. It is very often used in sample exam scenarios

Usage of this word may be ambiguous. I would rather use sequence instead.

Insurance Policy text alignment differ from the other elements

As this is not the case for all use cases I would add that in some cases it is the only valid one to connect some elements.

I also use examples with zero or indifferent influence to explicitly show that something is not going to influence something else. Should it be added?

I would add some statement to this chapter about naming the concepts. That similar to spoken language concepts have names where for elements is almost always specified (also exchange file format requires elements to have names) while fot relationships and junctions they are allowed but used rarely.

I would mention that the strength is not a name for the relationship and influence can have both name and strength in parallel

I would rephrase it because active structure element really does something (=process or function) and as part of that, passive element is acessed.

Please change the order to active-behaviour (left to right)

I think it applies to other elements (e.g. composite) too, but I would keep the definition as it is because this would be the majority of the use cases.

Billing data font size seems to be bigger than for the other elements

I would switch the order of the structural and dependency relationships according to their weights. Now it is exactpy opposite.

The same comment for grouping applies here as for the assignment description.

The arrow is too big (and line too short) compared to the other relationships.

I don't think that using grouping in this case will have the same meaning as using the junction. Grouping definition does not define this meaning and according my understanding of the note at the end of the Grouping chapter it specifies exactly the opposite ("contents of the group together, or parts thereof,")

... or a material inside an equipment that stores it.

We discussed to allow this for specialization to express that one relationship specializes other relationship (e.g. flow). But I understand it is too big change whith potential huge impacts.

Aggregation "Diamonds" overlapping the element looks odd, can you please make the picture a bit higher to avoid that?

Singular form should be used.

I very often receive the question on the difference between logical location and facility. E.g. branch, warehouse etc. may be expresses by both. Can we be more precise on explaining that? Or should the location be used solely for the physical location and logical left to the facility?

I meet many people experienced in BPMN who think that using the event in process descriptions is mandatory. Can we add a simple statement like "Unlike in BPMN, expressing events when modelling process is not mandatory and is left upon modeller?"

Process second row names are strangely aligned (not centred like if there is a space in front of them. The roles and collaborations have different sizes and are not horizontally aligned.

I would not propose any specific attributes to concepts. What about proposing such in a separate list in an appendix table (similar to what TOGAF has)?

Too IT focused, missing physical technology here.

Can path or its derivates provide service too? Distribution network can distributes goods, communication network can transfer data which both can be expressed as a service.

It is too detail to mention properties here. We removed them in other cases (impl. events) in the past too. Also using the word aggregates here might be confusing as readers may understand it as a relationship type.

Mixing singular and plural (which might be OK in English).

The previous comment to Interface applies here too

In some areas it is also common to describe instances, like departments are instances of an actor and very ofthe the technology domain describes the instances too (particular servers).

Is there some more detailed guidance on this? I would never think of it this way. If I have a department it would consists of sub-departments, application component of functions (assignment) etc.

Not an expert in data modeling, for me the concept is more familiar from Zachman framework in which some more levels are defined but more importantly word physical means the physical implementation and is not limited to data storages etc.

Physical here has different meaining than physical elements and should be explained.

Not only - see my previous comment to 3.4

Maybe example showing the same difficulty between IT and physical may help as well. E.g. printer can be expressed both device and equipment.

I thin "also called" has slightly different meining. I understand interface as on of potential many external active structure elements (they could be specializaed in parallel to interface) nut also called means that they are the same. The same applies to services below.

Add explanation on meaning of the relationships too. They should not be understood as ArchiMate relationship. Then each of them should be explained. I would also consider removing the composition for the model to concept as the composition is on later metamodels depicted by using normal link (triggering like one - see 4.3)

I would avoid using this very specific use case as an example of cross-domain relationship.

I would rephrase it to active tense which is more natural and will be consistent with realization description below.

I would also add something like: Those who would like to create easy to understand structured visualizations and/or models.

Is this statement needed? I would limit links to TOGAF to minimum. Also the statement is not true as the ArchiMate definitions are many time intentionally different to TOGAF counterparts.

This is more an example of a "horizontal" use of influence and not a "vertical" one as stated in the beginning of the next paragraph. (JB)

Add that definition have been updated wherever needed to avoid relying on abstract elements (JB)

We should add a requirement to support the Exchange FIle Format to make it explicit

Redundant use of "of the enterprise". This could be simplified to: The Technology Domain elements are typically used to model the structure and behavior of the technology infrastructure of the enterprise.

(JB)

Now that Contract has been removed, do we want to add some text to explain that a business object can also be a contract ? (JB)

Shouldn't there be some additional explanation for path? E.g., difference with network, naming, main relations, etc. The other elements have this, and there also was an explanation when Path was still in the technology layer (although this text will have to be modified because the use of Path has been extended).

Henk

First, by means of the specialization of concepts, as described in (AP)

only one way (specialization) is described here.... what are the other two?

Eventually, the whole sentence should be: The ArchiMate language has many ways of modeling such abstractions in the application domain, as described in....

Also, I suggest that the first sentence is joined to the previous paragraph, leaving the discussion of abstractions in the technology domain separated. (AP)

depicted in the metamodel figures in white boxes with label in italics (AP)

maybe "conceptual" instead of "global" (AP)

Should the Artifact icon be the same as the Business and Data Object icon?

comprises both information technology and operational (physical) technology that enable and support the enterprise operating model

depicts the organization structure and behavior (AP)

depicts the applications' structure and behavior (AP)

passive structure

Henk

active structure

Henk

Shouldn't there be some additional explanation for path? E.g., difference with network, naming, main relations, etc. The other elements have this, and there also was an explanation when Path was still in the technology layer (although this text will have to be modified because the use of Path has been extended).

Henk

Should we still use the term 'collective behavior'? We don't have a separate element to model collective behavior anymore.

Henk

passive structure

Henk

I thought we agreed to use C to indicate common elements instead of B, A or T (this is also in the text about notational cues).

Henk

active structure

Henk

This is a bit strange now. Although the physical elements are now completely integrated in the technology domain, the previous examples only use elements from the original (information) technology layer, while this overall example of the technology layer only uses physical elements.

Henk

This is no longer true, because collaborations now also perform processes or functions.

Henk

Shouldn't there be some additional explanation for path? E.g., difference with network, naming, main relations, etc. The other elements have this, and there also was an explanation when Path was still in the technology layer (although this text will have to be modified because the use of Path has been extended).

Henk

Should we still use the term 'collective behavior'? We don't have a separate element to model collective behavior anymore.

Henk

Interaction no longer exists, "Adjudicate High-Risk Claim" should be replaced with a process.

Henk

Placement of notation figures in this chapter is not consistent with the other chapters. Everywhere else, the notation figures are placed after the additional explanation, not directly after the definition.

Henk