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

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

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

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

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.

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

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

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

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

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

I suggest to remove this part as: 1) material is missing, and 2) the following paragraphs provides similar (but accurate) information. (JB)

I'd make explicite that Value Stream influences Value. As stated by Milan, we could also discuss an additional realization (with the same distinction than for requirement: if the Value Stream contributes to the Value, then influence, if it is mandatory to get this value, then realization).

I'd also make it explicit that Work Package realizes Course of Action. Of course that's already possible as a derived relationship (through deliverable, core elements, and strategy behavior elements), but that's also true directly as a course of action is made concrete and actionable through multiple programs and projects, modeled as work packages.

(JB)

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

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

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

I would add "and domains"

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

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

depicts the applications' structure and behavior (AP)

depicts the organization structure and behavior (AP)

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 would also add something like: Those who would like to create easy to understand structured visualizations and/or models.

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)

For internal consistency, this example should be updated as it describes the same collaboration than in "Figure 13. : Common Domain Elements", but with different members. (JB)

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

We might want to update to the latest version of 42010 which fixes it. See http://www.iso-architecture.org/42010/cm/

(JB)

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

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

Inconsistent junction naming compared to chapter 5.5.

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

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

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

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

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.

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.

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

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.

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.

Most of it is already part of the definition.

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?

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.

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

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

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?

Icon notation scaled differently than the icon in boxed notation

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.

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

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

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

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.

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.

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.

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

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

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

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

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?

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

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.

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

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.

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 rephrase it because active structure element really does something (=process or function) and as part of that, passive element is acessed.

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

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

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

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

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.

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

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.

Singular form should be used.

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

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 maybe add the third which is the structuring of a diagram to become more easily readable.

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

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.

Too IT focused, missing physical technology here.

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)

Lets deprecate it finally within this major version.

I guess it's time to remove this paragraph. (JB)

Add a reference to the chapter on Language Customization Mechanisms where this notion of specialization (profiles) is explained.

Image should be updated to match domains and no more layers (JB)

Wrong meaning icon notation

As discussed during a meeting (during Marc's holidays), this sentence is wrong as it suggests we can authorize relationships to/from a specialized element that would otherwise not be allowed on the "root" element. (JB)

Proposal: "but some of the relationships that apply to the generalized element need not be allowed for the specialized element.

For reference, in 2.1, used to be "Specialized concepts inherit the properties of their “parent” concepts, but additional restrictions with respect to their use may apply. For example, some of the relationships that apply to the “parent” concept need not be allowed for the specialization."

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

concepts should be used here.

Fix reference to Common Domain chapter (JB)

We might want to update to the latest version of 42010 which fixes it. See http://www.iso-architecture.org/42010/cm/

(JB)

Now that role is a generic element, I think we should replace role assigned to workpackage by business actor assigned to work package (for the same reasons that role can no more be assigned to a stakeholder). (JB)

edit: or if we decide to keep role here, then we might want to do the same with stakeholder.

@MarcLankhorst I think we should discuss this during today's call.

This small section could be removed as it adds nothing and does not exist in other chapters. (JB)

"Passive Structure Elements" section is missing. (JB)

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

Any element can aggregate elements of the same type. Using the word "composite" is ambiguous at best and lead people think it is a composite element.

I suggest to remove this sentense.

(JB)

Let's also mention data center here.

I would remove this advice because, while prior to ArchiMate 3 Node used to be the best concept to model a server encompassing hardware (device) and (system) software, since ArchiMate 3.2, Node can no more really be used for that purpose because several relationships have been removed (such as Communication Network aggregates Node).

This implies that now, Device has to take over Node to model a server (hard+soft), and thus its name cannot be restricted to type of hardware.

(JB)

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 only Path, but also Communication and Distribution Networks. (JB)

@MarcLankhorst. I think we should add Path (realized by both networks) to this metamodel diagram. Or else this relationship will be only in the text and nowhere else.

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

Change to "collaboration".

The end of this sentence is missing. Previously we had "and individual parts of such applications, at all relevant levels of detail." which makes sense. (JB)

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.

Technically speaking, with the new Common Domain metamodel, application components are assigned to roles, which in turn are assigned to behavior.

Maybe we can rephrase a bit: "An application component may be assigned (through a role) to one or more..."

(JB)

Is this sentence still needed (added in ArchiMate 3.0 to emphasis the generic metamodel) ? (JB)

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

Should be with capital letters as all previous examples.

I suggest to remove this part as: 1) material is missing, and 2) the following paragraphs provides similar (but accurate) information. (JB)

"be" is missing: "which can be manipulated". (JB)

singular should be used

For internal consistency, this example should be updated as it describes the same collaboration than in "Figure 13. : Common Domain Elements", but with different members. (JB)

Figure should be moved at the end of the section. (JB)

Me should avoid using the word "resources" as we don't speak about the Resource concept. (JB)

Fix reference to Common Domain chapter (JB)

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?

I'd make explicite that Value Stream influences Value. As stated by Milan, we could also discuss an additional realization (with the same distinction than for requirement: if the Value Stream contributes to the Value, then influence, if it is mandatory to get this value, then realization).

I'd also make it explicit that Work Package realizes Course of Action. Of course that's already possible as a derived relationship (through deliverable, core elements, and strategy behavior elements), but that's also true directly as a course of action is made concrete and actionable through multiple programs and projects, modeled as work packages.

(JB)

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

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?

Should be "from the internal/external distinction from the Common, Business, Application, and Technology Domains". (JB)

Should now be "Business and Common Domains elements". (JB)

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

The definition should be changed, Roles should not be assigned to Stakeholders. This was already discussed in one of our meetings. (ML)

passive structure

Henk

active structure

Henk

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

The accompanying text from previous versions is gone. I think this is a mistake. (JB)

Here's the original text: This definition is based on the definition in the TOGAF framework [4]. A stakeholder has one or more interests in, or concerns about, the organization and its Enterprise Architecture. In order to direct efforts to these interests and concerns, stakeholders change, set, and emphasize goals. Stakeholders may also influence each other. Examples of stakeholders are the Chief Executive Officer (CEO), the board of directors, shareholders, customers, business and application architects, but also legislative authorities. The name of a stakeholder should preferably be a noun.

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

Can we really describe dynamic relationships as "temporal dependencies". This looks too close to the sole definition of triggering, and also suggest that they are a subset of dependency relationships.

Maybe we could explain that, while structural and dependency relationships model the system "at rest", dependency relationships model the system "in motion".

(JB)

Should be "Motivation Domain"

The image should be updated to remove parenthesis. (JB)

We should avoid the word "path" as it could be interpreted as the Path element.

Replace with "A chain of junctions and relationships of a specific type is only allowed..."

(JB)

This should be the definition and not an accompanying text. We should even use the definition from chapter 2 which is more precise: "A [junction is a] concept that connects two or more relationships of the same type."

(JB)

This should be an accompanying texte and not the definition (JB)

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 propose to add word "some"

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

Backslash is not needed (JB)

Why do we have a backslash? Shouldn't it be a slash? (JB)

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

Rephrase here according to change above too

We had a discussion about clarifying that in addition to these CRUD meanings, some other was possible, such as transport (in conjunction with material). I thought we had an issue for that but I can't find it. I think we should discuss it again. (JB)

Using "realizing" here could lead to misinterpretation. I suggest to remove it. (JB)

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

Maybe we should add business actor / application component assigned to business / data object in this description (or remove the bit about node and technology passive structure elements (JB)

The definition should be changed, Roles should not be assigned to Stakeholders. This was already discussed in one of our meetings. (ML)

Should be "Motivation Domain". (JB)