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.

Too specific, standard should not prescribe.

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

Concepts should be used here as it applies to junctions too.

concepts should be used here.

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

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

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?

Wrong meaning icon notation

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 would be precise to say it is Plateau composite element.

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).

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

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

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.

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

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."

not only railways so I would add "e.g." or something similar.

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.

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).

The icon chimney is somewhat broken

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

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.

While true I would not state this in the definition but in the description below (it already is). I think that definitions should not state anything in brackets.

This sentence does not make sense. Drawing something inside refers to some relationship (nesting). The sentences can be understood that putting something in the node is enough and no relationship is needed ... BTW also access can be used and nested in this case.

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.

Please avoid examples with application collaboration for the reason mentioned above.

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.

I would remove it. Applications cannot agree by themselves to create a collaboration, for this domain it makes the least sense and I would not mention it at all. Allow it in the definitions and relationships but not proactively propose using that.

I thin access nesting is not needed anymore as we allowed assignments for passive objects.

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

The word elements is twice in the sentence, should be removed or rephrased.

Should be with capital letters as all previous examples.

Most of it is already part of the definition.

singular should be used

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.

Do we need to show Service and Internal Behaviour Element? Wouldn't it be easier just to show Behaviour element? Or do we want to say by the picture that Work package does not realize Strategy Behaviour Element?

The icon notation for values treams looks odd. Value stream stages are not aligned within the bigger values stream and the flow arrows are not well visible. What about changing it to boxed notation?

Isn't the value realized byt the value stream? We may be missing this relationship for value.

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

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

Another case for previously discussed grouping meaning

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

Role should be added to Business Actor to be assigned Stakeholder as it is part of the stakeholder definition.

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

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.?

And the best way to express the conformance is the influence and not a realization... (Still having troubles with requirements realizing principles ...

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

It point to actual chapter. Should be removed, probably left when moving from another chapter to this one.

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

Avoid word usually. The standard defines that it is either boxed (with diagonal edges) or icon notation.

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

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

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

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

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?

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

Ca also junction have a name? I expect so.

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).

I think the word instance is not valid here as I can use it for example between application as a category (class) and its versions or installations (instances). I would rephrase it that it is allowed between elements of the same type. (Also mention, that if it is allowed between relationships, the word element should be changed to concept)

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

I propose to add word "some"

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

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

We should avoid using blue for service part in A. When changing the picture, please set the height of service A to the same as for the process B to make it more consistent. Please swhitch the order of the right part to behaviour - passive (left to right).

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 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 also use examples with zero or indifferent influence to explicitly show that something is not going to influence something else. Should it be added?

Rephrase here according to change above too

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

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.

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

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

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

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.

Please move the active element (interface) to the left to keep active-behaviour-passive order. Also replace composition with aggregation. I would also change the applicaiton's ambiguous name Finance to something like Financial application, ERP, ...

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.

Lets deprecate it finally within this major version.

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

Singular form should be used.

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.

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?

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.

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 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?"

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)?

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

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.

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.

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

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

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.

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.

Not only - see my previous comment to 3.4

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.

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

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)

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 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.

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

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

I would add "and domains"

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.

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

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

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