Part of the Style Guide draft can be reused.

JB

To be rewritten to comply with ArchiMate 4 and previous changes.

JB

To be emphasised

JB

Explain that in this example, nested is used to suggest that Blood and Nutients are "inside" the body, while other passive structures are ultimately outside.

JB

Serving starting from an active structure should have a name to describe "what" is offered/supports the target element.

JB

Trigger targeting an active structure element should have a name describing "what" is triggered.

JB

Naming: flows should always have a name to describe "what" is flowing.

JB

Remove the "organs" from the process steps name (organs are active structure).

JB

Fix the figure: "carbon dioxide" goes FROM "Carrying wastes away" TO "Eliminating carbon dioxide"

JB

Aggregation

JB

Aggregation (also change accordingly below).

JB

Missing space.

JB

Explain that Service, Process and Function are real ArchiMate elements types, not abstract ones.

JB

Add some text to explain the usual naming conventions or constraints: behavior bust contain a verb or verb-like work as that's something which is done.

JB

Aggregation

JB

Aggregation

JB

Update all figures to use dashed or dotted outlines to denote abstract elements. Explain it somewhere.

JB

Switch to "Aggregation" as the prefered relationship. Maybe add a footnote to explain the paradigm shift in ArchiMate 4.

JB

Should be replaced by "In addition, some elements are abstract ones".

Rationale: behavior elements are now merged and thus are "real" elements. "generic" could be misinterpreted as "common", "abstract" seems a better choice.

JB

"Matamodel" should be "Metamodel"

JB

This section has to be rewritten as the definition and list of domains changed a bit between 3.x and 4.

JB

Add a new bullet point to shortly describe ArchiMate 4.

It might be good to also update the figure below to use the ArchiMate Hexagonion.

JB

Do we keep "layer" (was the name at that time) or not?

JB

Do we keep "layers" (was the name at that time) or not?

JB

Do we keep "layers" (was the name at that time) or not?

JB

Emphasis needed to better match the name fo this perspective shown in the figure.

JB

Emphasis needed to better match the name fo this perspective shown in the figure.

JB

Emphasis needed to better match the name fo this perspective shown in the figure.

JB

Emphasis needed to better match the name fo this perspective shown in the figure.

JB

Check near the end of the work if this still applies.

JB

Put "domain" into plural and change "layers" to "domains".

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)

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

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

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)

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)

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.

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)

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)

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)

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)

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)

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)

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)

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)

"or role" should be removed. (JB)

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.

Update: Grouping represents.....

The image should be updated to remove parenthesis. (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)

Junction is also defined in Chapter 5 (different wording btw). Maybe we should remove it from Chapter 2. (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 an accompanying texte and not the definition (JB)

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)

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

Backslash is not needed (JB)

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

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)

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)

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

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

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)

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

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)

No more true. Should be removed (JB)

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)

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)

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

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

Misprint: "clearly" (JB)

Add that definition have been updated wherever needed to avoid relying on abstract elements (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"

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)

Unwanted opening bracket "[" (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)

That's the opposite for specialization (JB)

WHat's the rule when mentioning other registered standards or trademarks ? Should maybe be UML(R) and BPMN(TM) (JB)

Shouldn't we add a (R) mention ? (JB)

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

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

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)

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)

Misprint: Technology (JB)

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

Fix reference to Common Domain chapter (JB)

Fix reference to Common Domain chapter (JB)

Fix reference to Common Domain chapter (JB)

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)

Fix reference to Common Domain chapter (JB)

Is plural really needed ? (JB)

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

This is no more true.

JB

This is no more true.

JB

active structure

passive structure

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

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.

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.

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

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

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

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

dksjg kjdsqgjkfgqskfgjqds

To be updated

Chapter has been renamed

This should be changed with the real version of the specs. Do we agree that this will be 4.0?

This chapter no more exists