ArchiMate

Modeling Guide
For the NATO Architecture
Framework Version 4
Architecture Capability Team
Digital Policy Committee 31/01/2025
Contents

1 INTRODUCTION ................................................................................................................... 5
1.1 Changes in this version ...................................................................................................... 5
1.2 Introduction and Overview................................................................................................ 5
1.2.1 About this Document....................................................................................... 5
1.2.2 The NAFv4 Viewpoints ..................................................................................... 6
1.2.3 ArchiMate Layers ............................................................................................. 6
1.3 How to Read ...................................................................................................................... 7
1.3.1 The Structure of this Document ...................................................................... 7
1.3.2 Specialisms....................................................................................................... 8
1.3.3 Tool Requirements for Implementation .......................................................... 8
1.3.4 Interpreting the Viewpoints ............................................................................ 8
1.3.5 Implementation/Guidance Text ...................................................................... 9
1.4 Known Issues ..................................................................................................................... 9
2 CONCEPT GLOSSARY................................................................................................... 10
2.1 Concepts Glossary ........................................................................................................... 10
3 C1 - CAPABILITY TAXONOMY .................................................................................... 11
3.1 C1 Object [by NAF Layer] ................................................................................................ 11
3.2 C1 Implementation Guidance ......................................................................................... 11
4 C2 - ENTERPRISE VISION............................................................................................. 12
4.1 C2 Objects [by NAF Layer] .............................................................................................. 13
4.2 C2 Implementation Guidance ......................................................................................... 13
5 C3 - CAPABILITY DEPENDENCIES ............................................................................. 14
5.1 C3 Objects [by NAF Layer] .............................................................................................. 15
5.2 C3 Implementation Guidance ......................................................................................... 15
6 C4 - STANDARD PROCESSES ....................................................................................... 16
6.1 C4 Objects [by NAF Layer] .............................................................................................. 17
6.2 C4 Implementation Guidance ......................................................................................... 17
7 C5 - EFFECTS ................................................................................................................. 18
7.1 C5 Objects [by NAF Layer] .............................................................................................. 19
7.2 C5 Implementation Guidance ......................................................................................... 19
8 C7 - PERFORMANCE PARAMETERS .......................................................................... 20
8.1 C7 Objects [by NAF Layer] .............................................................................................. 21
8.2 C7 Implementation Guidance ......................................................................................... 21
9 C8 - PLANNING ASSUMPTIONS ................................................................................... 22
9.1 C8 Objects [by NAF Layer] .............................................................................................. 23
9.2 C8 Implementation Guidance ......................................................................................... 23
10 CR - CAPABILITY ROADMAP ...................................................................................... 24
10.1 Cr Objects [by NAF Layer] ............................................................................................... 25
10.2 Cr Implementation Guidance ......................................................................................... 25
11 SERVICE GLOSSARY .................................................................................................... 26
11.1 Service Glossary .............................................................................................................. 26
12 S1 - SERVICE TAXONOMY ........................................................................................... 27
12.1 S1 Objects [by NAF Layer] ............................................................................................... 28
12.2 S1 Implementation Guide ............................................................................................... 28
13 S2 - SERVICE STRUCTURE ........................................................................................... 29
13.1 S2 Objects [by NAF Layer] ............................................................................................... 30
13.2 S2 Implementation Guidance ......................................................................................... 30
14 S3 - SERVICE INTERFACES .......................................................................................... 31
14.1 S3 Objects [by NAF Layer] ............................................................................................... 32
14.2 S3 Implementation Guide ............................................................................................... 32
15 S4 - SERVICE FUNCTIONS ............................................................................................ 33
15.1 S4 Objects [by NAF4 Layer] ............................................................................................. 34
15.2 S4 Implementation Guidance ......................................................................................... 34
16 S5 - SERVICE STATES ................................................................................................... 35
16.1 S5 Objects [by NAF Layer] ............................................................................................... 36
16.2 S5 Implementation Guidance ......................................................................................... 36
17 S6 - SERVICE INTERACTIONS ..................................................................................... 37
17.1 S6 Objects [by NAF Layer] ............................................................................................... 38
17.2 S6 Implementation Guidance ......................................................................................... 39
18 S7 SERVICE I/F PARAMETERS .................................................................................... 40
18.1 S7 Objects [by NAF Layer] ............................................................................................... 41
18.2 S7 Implementation Guidance ......................................................................................... 41
19 S8 - SERVICE POLICY ................................................................................................... 42
19.1 S8 Objects [by NAF Layer] ............................................................................................... 43
19.2 S8 Implementation Guidance ......................................................................................... 43
20 SR - SERVICE ROADMAP ............................................................................................. 44
20.1 Sr Objects [by NAF Layer] ............................................................................................... 45
20.2 Sr Implementation Guidance.......................................................................................... 45
21 C1-S1 SERVICE TO CAPABILITY MAPPING .............................................................. 46
21.1 C1-S1 Objects [by NAF Layer] ......................................................................................... 47
21.2 C1-S1 Implementation Guidance .................................................................................... 47
22 LOGICAL GLOSSARY ................................................................................................... 48
22.1 Logical Layer Glossary ..................................................................................................... 48
23 L1 - NODE TYPES ........................................................................................................... 50
23.1 L1 Objects [by NAF Layer] ............................................................................................... 51
 23.2 L1 Implementation Guidance ......................................................................................... 51
24 L2 - LOGICAL SCENARIO............................................................................................. 52
24.1 L2 Objects [by NAF Layer] ............................................................................................... 53
24.2 L2 Implementation Guidance ......................................................................................... 53
25 L2-L3 - LOGICAL CONCEPT ........................................................................................ 54
25.1 L2-L3 Objects [by NAF Layer] .......................................................................................... 55
25.2 L2-L3 Implementation Guidance .................................................................................... 55
26 L3 - NODE INTERACTIONS .......................................................................................... 56
26.1 L3 Objects [by NAF Layer] ............................................................................................... 57
26.2 L3 Implementation Guidance ......................................................................................... 57
27 L4 - LOGICAL ACTIVITIES .......................................................................................... 58
27.1 L4 Objects [by NAF Layer] ............................................................................................... 59
27.2 L4 Implementation Guidance ......................................................................................... 59
28 L5 - LOGICAL STATES .................................................................................................. 60
28.1 L5 Objects [by NAF Layer] ............................................................................................... 61
28.2 L5 Implementation Guidance ......................................................................................... 61
29 L6 LOGICAL SEQUENCE .............................................................................................. 63
29.1 L6 Objects [by NAF Layer] ............................................................................................... 64
29.2 L6 Implementation Guidance ......................................................................................... 64
30 L7 - INFORMATION MODEL ........................................................................................ 65
30.1 L7 Objects [by NAF Layer] ............................................................................................... 66
30.2 L7 Implementation Guidance ......................................................................................... 66
31 L8 - LOGICAL CONSTRAINTS ..................................................................................... 67
31.1 L8 Objects [by NAF Layer] ............................................................................................... 68
31.2 L8 Implementation Guidance ......................................................................................... 68
32 LR - LINES OF DEVEOPMENT ..................................................................................... 69
32.1 Lr Objects [by NAF Layer]................................................................................................ 70
32.2 Lr Implementation Guidance .......................................................................................... 70
33 PHYSICAL GLOSSARY ................................................................................................. 71
33.1 Physical Layer Glossary ................................................................................................... 71
34 P1 - RESOURCE TYPES ................................................................................................. 74
34.1 P1 Objects [by NAF Layer] .............................................................................................. 75
34.2 P1 Implementation Guidance ......................................................................................... 75
35 P2 - RESOURCE STRUCTURE ...................................................................................... 77
35.1 P2 Objects [by NAF Layer] .............................................................................................. 78
35.2 P2 Implementation Guidance ......................................................................................... 78
36 P3 - RESOURCE CONNECTIVITY ................................................................................ 80
36.1 P3 Objects [by NAF Layer] .............................................................................................. 81
36.2 P3 Implementation Guidance ......................................................................................... 81
37 P4 - RESOURCE FUNCTIONS........................................................................................ 83
37.1 P4 Objects [by NAF Layer] .............................................................................................. 84
37.2 P4 Implementation Guidance ......................................................................................... 84
38 L4-P4 - ACTIVITY TO FUNCTION MAPPING ............................................................. 86
38.1 L4-P4 Objects [by NAF Layer].......................................................................................... 87
38.2 L4-P4 Implementation Guidance .................................................................................... 87
39 P5 - RESOURCE STATES ............................................................................................... 89
39.1 P5 Objects [by NAF Layer] .............................................................................................. 90
39.2 P5 Implementation Guidance ......................................................................................... 90
40 P6 RESOURCE SEQUENCE ........................................................................................... 92
40.1 P6 Objects [by NAF Layer] .............................................................................................. 93
40.2 P6 Implementation Guidance ......................................................................................... 93
41 P7 - DATA MODEL ......................................................................................................... 94
41.1 P7 Objects [by NAF Layer] .............................................................................................. 95
41.2 P7 Implementation Guidance ......................................................................................... 95
42 P8 - RESOURCE CONSTRAINTS ................................................................................... 96
42.1 P8 Objects [by NAF Layer] .............................................................................................. 97
42.2 P8 Implementation Guidance ......................................................................................... 97
43 PR - CONFIGURATION MANAGEMENT ..................................................................... 98
43.1 Pr Objects [by NAF Layer] ............................................................................................... 99
43.2 Pr Implementation Guidance ......................................................................................... 99
 NAFv4@ArchiMate 5

1 INTRODUCTION

1.1 Changes in this version

Ref. Change
CR1 Added Triggering Relation from Operational Activity to Operational Activity to represent
‘logical flows between activities’.
CR2 Section 1.2.1 wording amended to clarify this mapping is to the types of objects rather
than the viewpoints specifically.
CR3 Section 1.2.1 wording added to clarify the fact that this is a guidance document and
programme level architects should acknowledge the needs of their specific program of
work
CR4 Section 1.3.1 elaborated the heading definitions of implementation guidance tables, to
clarify sources of table contents
CR5 Section 1.3.2 Deletion of misleading use of ‘application’
CR6 Section 1.3.2 updated to reflect that all elements are specialisations
CR7 Section 1.3.3 wording modified slightly to reflect that this is a general requirement of
tooling, not specific to modelling
CR8 Addition of known/unresolved issues table. Section 1.3
CR9 Glossary tables updated to include parent ArchiMate element type. Noting also that
mapping is also provided as part of implementation guidance
CR10 Glossary tables updated to include previously missing elements from the guidance.
CR11 Additional rationale added to NAF4 ArchiMate element descriptions where
specialisations are most deviant from ArchiMate standard
CR12 Corrected various instances where the mandatory/optional nature of elements and
objects was incorrectly represented.
CR13 Missing description for C9 added
CR14 Amendments to Logical layer viewpoints L1, L3 & L4 to clarify usage of Role and
Interactions
CR15 Amendment to L1 to accommodate the specific Measure of Performance (MoP).
CR16 Views updated to be conformant with ‘Box’ views from ArchiMate 3.2
CR17 Numbering updates following these changes

1.2 Introduction and Overview

1.2.1 About this Document

This document refers to Chapter 4, Section 2.2, of the NATO Architecture Framework (NAF) version 4.
It provides guidance on how to develop NAFv4 compliant architectures based on the ArchiMate 3.2
specification.
The NATO Architecture Framework document concerns all nations or organizations using the NAF. It
is provided and maintained by the NATO Architecture Capability Team (ACaT). The ArchiMate
modeling guidelines (i.e. this document) concern all nations or organizations using the ArchiMate
modelling language for their architecture development. Because tools and specific extensions of
framework and language may differ between nations or organizations, these aspects are not
considered in this document. Nations or organizations need to provide and maintain additional
guidelines in order to cover these aspects themselves.
This specialized version of NAF has been built using the following principles:
 6 NAFv4@ArchiMate

• Conciseness - Only elements and relationships that are directly relevant to the requirements
and objectives, especially in the context of NATO operations have been included on
viewpoints.
o We want to avoid having redundant relations and object types that are hardly used.
• Flexibility - Where practical and relevant, specialisms have been used.
o This allows specific tailoring of the ArchiMate Metamodel allowing for scalability and
adoption to evolving business requirements.
• Usability – Clarity of semantics and representation of architectural concepts, avoiding
ambiguity in design.
• Alignment – Whilst promoting simplicity and minimalism, priority has been given to making
sure the overall Metamodel aligns to the NAF v4 standard.
It has resulted in the minimum number of ArchiMate element use to fulfil the needs of NAFv4,
although there is some repetition of object usage. It is not intended to be a 1:1 mapping of
ArchiMate to NAFv4.
Addressed readers are
• Modelers required to produce NAFv4 compliant ArchiMate Models.
• Developers of national/organizational guidelines.
• Implementers of tool specific ArchiMate profiles.
It is noted that Architects at the program level may follow this document as guidance, but have the
freedom and flexibility to develop fit-for-purpose views and extend the metamodel as necessary to
suit their program needs. Due to program time and bandwidth constraints it is expected that they
produce a minimum viable architecture suitable for their program rather than slavishly creating the
entire set of views, supporting the viewpoints in this document

1.2.2 The NAFv4 Viewpoints

The NAF Grid Representation is a two-dimensional classification scheme for the standardized NAF
viewpoints, which serve as the baseline for any NAF-Compliant architecture effort. However, the
selection of Viewpoints must be tailored to the specific architecture effort, i.e. suitable Viewpoints
need to be identified in the grid, and additional Viewpoints must be defined, if and when required.
The grid approach presents the NAF viewpoints by Subjects of Concerns (rows) and by Aspects of
Concerns (columns). The NAF is arranged as a grid with columns as set of broad Model Kinds. For
more information, see the figure below and the main document NATO Architecture Framework
Version 4. N.B. The Architecture Foundation Layer is out of scope for this guide.

1.2.3 ArchiMate Layers

The ArchiMate Full Framework captures the viewpoints in the NAF Grid thusly;
 NAFv4@ArchiMate 7

Aspects from the ArchiMate Full Framework do not align explicitly to the viewpoints, however, the
shading of the vertical ‘aspects’ related to the fact that encapsulated viewpoints emphasize the use
of objects from these aspects, but are not limited to them. Due to the use of ArchiMate concepts in
multiple layers within the NAF Grid, specialization of ArchiMate concepts is required that is detailed
within the body of this document. Whilst in some cases there are terms in both NAF and ArchiMate
that share the same meaning, others do not. Care must be taken to understand which term the
document is referring to at any point in time, for example; Technology, Physical, Resource and Node.

1.3 How to Read

1.3.1 The Structure of this Document

For each row of the NAFv4 grid an ArchiMate extract is provided. Each Viewpoint (cell in the NAFv4
grid) is described by separate subsections containing:
• Information from the relevant section of the NAF
• ArchiMate extract relating to the viewpoint
• Implementation notes and mappings of ArchiMate to NAF objects
• In later iterations of this document modeling examples will also be provided.
Within the Implementation guidance section is included a table with 3 columns, this serves to
provide a mapping between NAFv4, standard ArchiMate, and the specialized objects as part of this
guide. In these tables the columns are;
NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name
The name provided in the The name of the specialized The name of the ‘parent’
NAFv4 framework ArchiMate element created for element from the ArchiMate
documentation. the purpose described in this specification from which the
document. NAFv4 specialization is derived
 8 NAFv4@ArchiMate

1.3.2 Specialisms
Specializing the ArchiMate metamodel is a necessity, and as such, all elements within this document
should be viewed as specialisms of the standard ArchiMate specification with some elements with
the only distinction being in how much the specialisms deviate from the standard.

Specialization addresses both;

• gaps in aligning the standard ArchiMate framework and NAFv4, and, in future
• exchange between different modelling languages

By tailoring ArchiMate elements to represent NAF-specific constructs, the resultant specialized

NAFV4 ArchiMate Metamodel becomes more effective and relevant for its intended purpose. This
specialization is fully supported by the ArchiMate specification, ensuring compliance while enabling
enhanced clarity and usability. For instance, the Application Component is used to represent a
Logical Node with the element name of '# Application Node' to reflect its specialized role. This
bridges the gap between standard notations and the specific needs of NAFv4.

1.3.3 Tool Requirements for Implementation

This guide is written as tool agnostic, but the minimum requirement for any ArchiMate modeling tool
is that it is capable of implementing the specializations required i.e. language, as per the ArchiMate
specification. The toolset must support the ability to either embed the specializations as attributes
for tagging elements or visually represent them as stereotypes on objects. These features are critical
to ensuring that the specialized framework is consistently applied and intuitive for users, enabling
effective modelling, analysis, and stakeholder communication.

1.3.4 Interpreting the Viewpoints

Elements on viewpoints show the specialization name and are prefixed with a #, such as '#
Application Node' making their extended purpose immediately clear. Elements are also colored
according to the NAF layer of which they are a part of. However, they retain the standard ArchiMate
notations to maintain familiarity and consistency for users. This approach ensures that the
specialized constructs remain intuitive while clearly conveying their specialized meaning within the
NAFv4 framework. This strikes a balance between representing standard notation and representing
extended functionality. See below for an example of the C4 viewpoint with default ArchiMate colors
Vs NAF layering colors. N.B. In ArchiMate there are no formal semantics around colors.
 NAFv4@ArchiMate 9

Bold borders represent mandatory (shall be present in the viewpoint) objects on a viewpoint,
otherwise objects are optional (may be present in the viewpoint).

Note that attributes/properties of elements are not visualized within the viewpoints, even when
mentioned in the description of the framework, but are specifically mentioned, where appropriate,
within the associated implementation guidance.

1.3.5 Implementation/Guidance Text

• Where terms refer to NAFv4 they will be bold
• For those that are ArchiMate specific they are italicized
As mentioned above, specialized elements are prefixed with ‘#’ in figures and tables, and identified in
the narrative as either Bold Italic where the ArchiMate Concept is a 1:1 mapping to the NAFv4
concept. In other cases the specialism is described by highlighting the NAFv4 Concept and drawing
the readers attention to how these map to one, or more, ArchiMate Concepts both in the narrative
and through tables as part of the Implementation Guidance sections for each viewpoint.
Below each viewpoint there will be a table with three columns ‘NAFv4 Name ‘, ‘NAFv4 ArchiMate
Name’, ‘ArchiMate Name’.

1.4 Known Issues

Within this document the following are acknowledged;
ID Description
1 The NAFv4 framework document provides insufficient clarity of Role leading to ambiguous
use as Business Role, [Logical] Node and Operational Performer [of an activity] in this
document. This is expected to be resolved in a later revision.
 10 NAFv4@ArchiMate

2 CONCEPT GLOSSARY

2.1 Concepts Glossary

NAFv4 ArchiMate Name ArchiMate Name Description

# Effect Outcome The consequence or outcome of an action.
# Enterprise Phase Plateau A current or future state of the enterprise. An
ArchiMate plateau is used here with the
rationale that it reflects the time dimension of a
roadmap effectively
# Concept Requirement Requirement A [Constraint] specified at the strategic level.
# Goal Goal The aim or outcome which a person, group, or
organization works towards or strives to
achieve.
# Measurement Category Requirement A supertype or logical grouping of
measurements
# Capability Capability The expected ability of one or more resources
to deliver a specified type of effect or outcome
or a specified course of action.
# Measurement Requirement Any measurement that can be used to define
the achivements delivered by a capabillity.
Since there is no specific ArchiMate element
that naturally maps to measurement
Requirement was chosen since a measurement
can often be how a requirement is, or is not
satisfied
# Work Package Work package
# MoE Requirement A specific measurement that can be used to
define the achivements delivered by a
capabillity
 NAFv4@ArchiMate 11

3 C1 - CAPABILITY TAXONOMY

C1 – Capability Taxonomy NAFv3: NCV-2

The C1 Viewpoint is concerned with the identification of capabilities, and their organization into
specialization hierarchies (taxonomies) independent of their implementation and may be referenced in
whole or part by, or used in, describing multiple architectures (e.g. a C1 View at Enterprise-level will be
referenced by C1 Views at the Capability-level).
Views implementing this Viewpoint
• Shall include all capabilities relevant for the architecture.
• Shall organize all capabilities into a specialization hierarchy.
• May include Measures of Effectiveness (MoE).
CONCERNS ADDRESSED USAGE
• Capability Planning. • Identification of existing and required
• Capability Management. capabilities.
• Source for the derivation of cohesive sets of
Key User Requirements (KURs).
• Providing reference capabilities for multiple
architectures.
REPRESENTATION
• Tabulation.
• Hierarchical (Connected Shapes).
• Diagram (with generalization relationships and property definitions).

3.1 C1 Object [by NAF Layer]

# MoE # Capability

3.2 C1 Implementation Guidance

Hierarchical relations of Capabilities are represented using the specialization relation, they serve the
same purpose as a UML generalization, but can be seen to propagate in the opposite direction.
Measures Of Effectiveness are represented here as a Requirement, as a specialisation of Measure
Catagory (C7).

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Measurement # MoE Requirement
Capability # Capability Capability
 12 NAFv4@ArchiMate

4 C2 - ENTERPRISE VISION

C2 – Enterprise Vision NAFv3: NCV-1

The C2 Viewpoint is concerned with scoping the architecture effort and providing the strategic context
for the capabilities described in the architecture.
Views implementing this Viewpoint:
• Shall describe the vision and goals for the capabilities in scope for a defined period (or periods) of
time.
• May include desired outcomes and measurable benefits associated with the goals.
• May link the capabilities to enduring tasks.
CONCERNS ADDRESSED USAGE
• Enterprise Strategy. • Capture and communication of the strategic
• Capability Planning. vision related to capability evolution.
• Identify the capabilities required to meet the
vision and goals.
• Identify the required timescales for the
capabilities (as opposed to Cr which provides
a summary of when projects are estimated to
deliver capability).
• Identify any enduring tasks the enterprise
performs.
• Provision of a blueprint for a
transformational initiative.
REPRESENTATION
• Structured Text.
• Composite Structure Diagram.
 NAFv4@ArchiMate 13

4.1 C2 Objects [by NAF Layer]

# Goal # Effect

# Enterprise
Phase

# Capability

4.2 C2 Implementation Guidance

This viewpoint must contain a Capability element. A Plateau is used to represent an Enterprise Phase.
In the context of the Enterprise lifecycle a Goal is realised by an Enterprise Phase. In order to link
desired outcomes or measureable benefits to Goals, these are realised by Effects, which are
represented by Outcomes. An Enterprise Lifecycle is a composition of sequential (triggered) Enterprise
Phases.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Enduring Task # Capability Capability
Capability # Capability Capability
EnterprisePhase # Enterprise Phase Plateau
WholeLifeEnterprise # Enterprise Phase Plateau
EnterpriseGoal # Goal Goal
Vision # Goal Goal
Desired Outcome # Effect Outcome
Benefit # Effect Outcome
 14 NAFv4@ArchiMate

5 C3 - CAPABILITY DEPENDENCIES

C3 – Capability Dependencies NAFv3: NCV-4

The C3 Viewpoint is concerned with identification of dependencies between capabilities, and defining
the logical composition of capabilities (i.e. capability clusters).
Views implementing this Viewpoint:
• Shall include all dependencies between capabilities relevant for the architecture.
• May defines logical groupings of capabilities by means of composition.
• May include capability specializations (Note, this can also be expressed in a C1 View).
CONCERNS ADDRESSED USAGE
• Capability Management. • Analysis of dependencies between
capabilities and between capability clusters.
• Impact analysis for capability options,
disposal of capabilities.
• Highlight potential integration requirements
and the interactions needed between
acquisition projects in order to achieve the
overall capability.

REPRESENTATION
• ‘Nested box’ diagram.
• Class diagram.
• Composite Structure diagram.
 NAFv4@ArchiMate 15

5.1 C3 Objects [by NAF Layer]

# Capability

5.2 C3 Implementation Guidance

Hierarchical relations of Capabilities are represented using the specialization relation, they serve the
same purpose as a UML generalization, but can be seen to propagate in the opposite direction.
The serving relation is mandatory here to show dependencies between Capabilities [outside of their
own hierarchy]

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Capability Cluster # Capability Capability
Capability # Capability Capability
 16 NAFv4@ArchiMate

6 C4 - STANDARD PROCESSES

C4 – Standard Processes NAFv3: NCV-6

The C4 Viewpoint is concerned with identification of standard activities (e.g. doctrinal) and optionally
with their traceability to the capabilities they support.
Views implementing this Viewpoint:
• Shall identify all standard activities relevant for the architecture.
• May provide a composition of these standard activities.
• May link capabilities to supporting standard activities.
A standard process list, in whole or parts, may be referenced by, or used in describing, multiple
architectures (e.g. a C4 View at enterprise-level will be referenced by C4 Views at the capability-level).
CONCERNS ADDRESSED USAGE
• Doctrine Production. • Specification of doctrine.
• Operational Analysis. • Tracing capabilities to enduring tasks.
• Tracing capabilities to standard operational
activities.
• Capability audit.

REPRESENTATION
• Tabular.
• Tracing Diagram.
 NAFv4@ArchiMate 17

6.1 C4 Objects [by NAF Layer]

# Capability

# Operational
Activity

# Standard
Operational
Activity

6.2 C4 Implementation Guidance

The Standard Operational Activity must be present in this viewpoint as a Business Process that is a
specialization of an Operational Activity which may be composed of other Operational Activities.
An Operational Activity may be traced back to a Capability via a realization relation.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Standard Operation Activity # Standard Operational Activity Business process
OperationalActivity # Operational Activity Business process
Capability # Capability Capability
 18 NAFv4@ArchiMate

7 C5 - EFFECTS

C5 – Effects NAFv3: NONE

The C5 Viewpoint is concerned with identifying and describing effects of capabilities. Views
implementing this Viewpoint:
• Shall define effects relevant for the architecture effort.
• Shall assign effects to capabilities.
• May identify start and/or end dates of effects.
• May identify resource types associated to start and end dates of effect.
• May show a specialization hierarchy of effects.
CONCERNS ADDRESSED USAGE
• Operational Analysis. • Characterization of the expected results
• Analysis of non-functional properties. capabilities, positive or negative.
• Analysis of cumulative effects.
• Analysis of persistence of the effects.
• Tracing the operational states and modes
with regards to the effects.
REPRESENTATION
• Tabular.
• Structural diagram.
• Histogram.
• Finite state diagram.
 NAFv4@ArchiMate 19

7.1 C5 Objects [by NAF Layer]

# Goal

# Effect

# Capability

# Enterprise
Phase

7.2 C5 Implementation Guidance

Both Effect, represented as an Outcome, and Capability must be present as part of the viewpoint. It
may have attribuites to signify the start and end dates of Effects
Capabilities are realized by an Enterprise Phase represented as a plateau. Goals may optionally be
shown on this viewpoint for traceability.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

CapabilityConfiguration # Capability Capability
Capability # Capability Capability
Effect # Effect Outcome
Benefit # Effect Outcome
EnterprisePhase # Enterprise Phase Plateau
EnterpriseGoal # Goal Goal
 20 NAFv4@ArchiMate

8 C7 - PERFORMANCE PARAMETERS

C-7– Performance Parameters NAFv3: NCV-1

The C7 Viewpoint is concerned with the identification and description of measure categories, and
identification of capabilities to which they are applicable.
Views implementing this Viewpoint:
• Shall identify all measure categories relevant for the architecture.
• May link measure categories to capabilities.
CONCERNS ADDRESSED USAGE
• Capability Planning. • Setting Capability Requirements.
• Capability Management. • Military Estimates.
• User Requirement Specification. • Strategic Reviews.
• Planning Assumptions.

REPRESENTATION
• Tabular (capabilities on one axis, measure categories on the other).
• Class diagram with property definitions.
 NAFv4@ArchiMate 21

8.1 C7 Objects [by NAF Layer]

# Measurement
Category

# Measurement # Capability

8.2 C7 Implementation Guidance

Measure Categories are properties of Capabilities each being composed of specific Measures.
Thesew attributes are visualised as Requirements.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Measure Category # Measurement Category Requirement
Capability # Capability Capability
MeasurementSet # Measurement Requirement
Measurement # Measurement Requirement
 22 NAFv4@ArchiMate

9 C8 - PLANNING ASSUMPTIONS

C8 – Planning Assumptions NAFv3: NONE

The C8 Viewpoint is concerned with identification and description of assumptions that have been made
for the implementation of capabilities.
Views implementing this Viewpoint:
• Shall contain capabilities relevant for the architecture.
• Shall include constraints for capability implementation.
• May include goals.
• May include assumed benefits.
CONCERNS ADDRESSED USAGE
• Capability Planning. • Implementation Planning.
• Planning Assumptions.

REPRESENTATION
• Tabular.
• Benefits diagram.
 NAFv4@ArchiMate 23

9.1 C8 Objects [by NAF Layer]

# Effect # Goal

# Concept
# Capability
Requirement

9.2 C8 Implementation Guidance

A Concept Requirement is used to represent a Constraint, realized by Capabilities. Capabilities

realize Effects which in turn realize Goals. In ArchiMate v3.2, the constraint is a specialization of a
requirement. Modelers can choose to use this notation if they prefer.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Constraint # Concept Requirement Requirement
EnterpriseGoal # Goal Goal
Benefit # Effect Outcome
Capability # Capability Capability
 24 NAFv4@ArchiMate

10 CR - CAPABILITY ROADMAP

Cr– Capability Roadmap NAFv3: NCV-3

The Cr Viewpoint is concerned with the representation of the actual or estimated availability of
capabilities over a period of time (derived from capability delivery milestones in acquisition projects).
Views implementing this Viewpoint:
• Shall identify capabilities related to the roadmap.
• Shall identify associated capability increments.
• May identify programmes or projects associated with the capability increments.
• May associate capability increments with specific periods of time.
CONCERNS ADDRESSED USAGE
• Capability Planning. • Capability phasing.
• Acquisition Management. • Capability integration planning.
• Capability gap/surplus analysis.
• High-level dashboard for acquisition
management.

REPRESENTATION
• A time based chart in the style of a Gantt chart.
 NAFv4@ArchiMate 25

10.1 Cr Objects [by NAF Layer]

# Enterprise
# Work Package # Capability
Phase

10.2 Cr Implementation Guidance

Plateaus are used to represent an Enterprise Phase, that realizes a specific Capability. Work
Packages represent Projects and Programs that deliver Capability Increments
Each Capability is specialised as a Capability Increment, with Milestone information as an attribute
of the Capbility Increment.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Perid of Time # Enterprise Phase Plateau
Roadmap # Enterprise Phase Plateau
Project # Work Package Work package
Program # Work Package Work package
Capability Increment # Capability Capability
Capability # Capability Capability
 26 NAFv4@ArchiMate

11 SERVICE GLOSSARY

11.1 Service Glossary

NAFv4 ArchiMate Name ArchiMate Name Description

# Technology Service Technology interface Exposes a Technology Service for
Interface consumption.
# Application Service Application interface Exposes an Application Service for
Interface consumption.
# Technology Service Technology service A [Service] which exposes technology
[Behaviour] or business value.
A means of providing value, functionality or
a product to a consumer (human or
machine) in a contracted way by hiding
associated risks and constraints.
# Service Requirement Requirement A constraint specified at the service level
# Application Service Application service A [Service] which exposes application
[Behaviour] or business value.
A means of providing value, functionality or
a product to a consumer (human or
machine) in a contracted way by hiding
associated risks and constraints.
# Service Operation Business function Enables programmatic communication with
a Business Service via a Business Service
Interface.
# Business Service Business service A [Service] which exposes business
[Behaviour] or business value. A means of
providing value, functionality or a product to
a consumer (human or machine) in a
contracted way by hiding associated risks
and constraints.
# Business Service Interface Business interface Exposes a Business Service for consumption.
# Service Operation Application function Enables programmatic communication with
an Application Service via an Application
Service Interface.
# Service Operation Technology function Enables programmatic communication with
a Technology Service via a Technology
Service Interface.
# Service Roadmap Plateau Canvas for a sequnce of plateaus
representing a [Roadmap] for the delivery of
[Service]s. An ArchiMate plateau is used
here with the rationale that it reflects the
time dimension of a roadmap effectively
# Service Policy Requirement A set of rules and constraints that specify
the non-functional aspects of a [Service].
Examples: Availability, Reliability, Safety,
Security, Useability.
 NAFv4@ArchiMate 27

12 S1 - SERVICE TAXONOMY

S1 – SERVICE TAXONOMY NAFv3: NSOV-1/NAV-2

The S1 Viewpoint is concerned with the identification of service specifications, and their organization
into specialization hierarchies (taxonomies).
Views implementing this Viewpoint:
• Shall include all service specifications relevant for the architecture.
• May organize all service specifications into a specialization hierarchy.
• May include measures for the service specifications.
• May include attributes for the service specifications.
A service taxonomy, in whole or parts, may be referenced by, or used in describing, multiple
architectures (e.g. a S1 View at enterprise-level will be referenced by S1 Views at the capability-level).
CONCERNS ADDRESSED USAGE
• Cataloguing Service Specifications. • Service-oriented architecture governance.
• Defining measures for Service Levels. • Identification of services.
• Specialization of Service Specifications. • Service planning.
• Service audit.
• Service gap analysis.
• Providing reference services for
architectures.
• Tailoring generic services for specific
applications.
REPRESENTATION
• Tabulation.
• Hierarchical (connected shapes).
• Class diagram.
 28 NAFv4@ArchiMate

12.1 S1 Objects [by NAF Layer]

# Business
Service

# Application
Service

# Technology
Service

12.2 S1 Implementation Guide

Services exist at 3 layers within ArchiMate. Where the layering of services is applicable to the
architecture, they must be present on the viewpoint.
Hierarchical relations of Services are represented using the specialization relation. This serves the
same purpose as a UML generalisation, but can be seen to propagate in the opposite direction. Since
ArchiMate does not allow specialization of Services between layers the serving relation (also in S2) is
used.
Each Service may have attributes which may include appropriate Measures for the Service.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Service Specification # Technology Service Technology service
Service Specification # Business Service Business service
Service Specification # Application Service Application service
 NAFv4@ArchiMate 29

13 S2 - SERVICE STRUCTURE

S2– Service Structure NAFv3: NSV-12/NSOV-2, 6

The S2 Viewpoint is concerned with the identification and specification of how services are structured
to create higher-aggregated services. To provide high-level views, dependencies to other services,
nodes and resources as well as service interfaces and service functions can be represented.
Views implementing this Viewpoint:
• Shall identify the structure of aggregated services.
• Shall identify dependencies between services.
• May specify dependencies between services and nodes or resources.
• May include service interfaces defined in S3.
• May include service functions defined in S4.
CONCERNS ADDRESSED USAGE
• Detailed Service Specifications. • Service composition.
• Requirements for Service compatibility. • Service dependency analysis.
• Service implementation guidance. • Service-oriented architecture governance.
• Service interoperability.

REPRESENTATION
• Tabular.
• Matrix.
• Dependency graph.
• Diagram.
 30 NAFv4@ArchiMate

13.1 S2 Objects [by NAF Layer]

# Business # Application
# Business # Application
Service Service # Technology
Service Service # Technology
Interface Interface Service
Service
Interface

# Application # Technology # Equipment

# Business Node
Node Node Node

# Business # Application # Technology

Function Function Function

13.2 S2 Implementation Guidance

Services, Service Interfaces and Functions exist at 3 layers within ArchiMate. Where this layering is
applicable to the architecture, this must be present in this viewpoint.
Nodes exist at 4 ArchiMate layers, depending on their layer are represented by Business Actor,
Application Component, Technology Node and Equipment
Dependency relations are represented by serving relations between Services with each Service
describing at least one Service Interface and realized by one or more Nodes. The Service Interface is
assigned to the Service.
A Node may have assigned Functions, in this context ArchiMate Functions are used to represent
Service Functions. These functions are the 'features' of the Node.
Further traceability to resources should be defined in the P2 viewpoint.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Service Function # Business Function Business function
Service Function # Application Function Application function
OperationalPerformer # Equipment Node Equipment
Node # Equipment Node Equipment
Node # Application Node Application component
OperationalPerformer # Application Node Application component
Service Interface # Application Service Interface Application interface
Service Function # Technology Function Technology function
Service Interface # Technology Service Interface Technology interface
Service Specification # Application Service Application service
Service # Application Service Application service
Node # Technology Node Node
OperationalPerformer # Technology Node Node
Service Specification # Business Service Business service
Service # Business Service Business service
Service Interface # Business Service Interface Business interface
Node # Business Node Business actor
OperationalPerformer # Business Node Business actor
Service Specification # Technology Service Technology service
Service # Technology Service Technology service
 NAFv4@ArchiMate 31

14 S3 - SERVICE INTERFACES

S3– Service Interfaces NAFv3: NSOV-2

The S3 Viewpoint is concerned with the identification and specification of service interfaces. Views
implementing this Viewpoint:
• Shall identify service interfaces provided by a service.
• May identify service interfaces required by a service.
• May identify operations for service interfaces.
• May specify service operations.
CONCERNS ADDRESSED USAGE
• Detailed Service Specifications. • Service-oriented architecture governance.
• Requirements for Service compatibility. • Detailed Service specification.
• Service implementation guidance. • Service interoperability.

REPRESENTATION
• Tabular.
• Diagram.
 32 NAFv4@ArchiMate

14.1 S3 Objects [by NAF Layer]

# Business
# Business
Service
Service
Interface

# Application
# Application
Service
Service
Interface

# Technology
# Technology
Service
Service
Interface

14.2 S3 Implementation Guide

Services and Service Interfaces exist at 3 layers within ArchiMate, where this layering is applicable to
the architecture, this must be present in this viewpoint.
Each Service may be assigned to one Service Interface.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Service Interface # Business Service Interface Business interface
Service Interface # Application Service Interface Application interface
Service Operation # Application Service Application service
Service # Application Service Application service
Service # Business Service Business service
Service Operation # Business Service Business service
Service # Technology Service Technology service
Service Operation # Technology Service Technology service
Service Interface # Technology Service Interface Technology interface
 NAFv4@ArchiMate 33

15 S4 - SERVICE FUNCTIONS

S4 – Service Functions NAFv3: NSOV-3

The S4 Viewpoint is concerned with the definition of the behaviour of a service in terms of the functions
it is expected to perform.
Views implementing this Viewpoint:
• Shall identify all functions a service is performing.
• May specify composition of service functions.
CONCERNS ADDRESSED USAGE
• Detailed Service Specifications. • Service specification & planning.
• Outline requirements for Service behaviour. • Governance.
• Service implementation guidance.

REPRESENTATION
• Tabular.
• Diagram.
 34 NAFv4@ArchiMate

15.1 S4 Objects [by NAF4 Layer]

# Business # Business
# Business Node
Service Function

# Application # Application # Application

Service Node Function

# Technology
Node

# Technology # Technology
Service Function

# Equipment
Node

15.2 S4 Implementation Guidance

Services and Service Functions exist at 3 layers within ArchiMate, where this layering is applicable to
the architecture, this must be present in this viewpoint.
Nodes exist at 4 ArchiMate layers, depending on their layer are represented by Business Actor,
Application Component, Technology Node and Equipment
A Node shall have assigned Functions, these are the 'features' of the Node
Services are depicted as being realized by Nodes. Therefore traceability between services and
functions is derived through nodes.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Service Function # Application Function Application function
Node # Equipment Node Equipment
Service # Application Service Application service
Service Function # Technology Function Technology function
Node # Business Node Business actor
Service # Technology Service Technology service
Service Function # Business Function Business function
Node # Technology Node Node
Service # Business Service Business service
Node # Application Node Application component
 NAFv4@ArchiMate 35

16 S5 - SERVICE STATES

S5– Service States NAFv3: NSOV-4B

The S5 Viewpoint is concerned with the identification and definition of the possible states a service may
have, and the possible transitions between those states.
Views implementing this Viewpoint:
• Shall identify and define all allowable states of a service.
• May describe possible state transitions.
• May describe service constraints.
CONCERNS ADDRESSED USAGE
• Detailed Service Specifications. • Service behaviour specification.
• Outline requirements for Service behaviour.
• Service implementation guidance.

REPRESENTATION
• Diagram.
• State transition model.
 36 NAFv4@ArchiMate

16.1 S5 Objects [by NAF Layer]

# Logical
# Business
Business
Service
Operational State

# Logical
# Service # Application
Application
Requirement Service
Operational State

# Logical
# Technology
Technology
Service
Operational State

16.2 S5 Implementation Guidance

Services exist at 3 layers within ArchiMate, Where this layering is applicable to the architecture, this
must be present in this viewpoint.
A Service shall be associated with one or more Operational States, as Events, that correspond to the
appropriate ArchiMate layer for the Service and may realise a Service Requirement.
Transitions between Operational States may be depicted using a triggering relation.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Service # Application Service Application service
Service # Business Service Business service
State # Logical Application Operational State Application event
Service # Technology Service Technology service
Constraint # Service Requirement Requirement
State # Logical Business Operational State Business event
State # Logical Technology Operational State Technology event
 NAFv4@ArchiMate 37

17 S6 - SERVICE INTERACTIONS

S6– Service Interactions NAFv3: NSOV-4C

The S6 Viewpoint is concerned with describing interactions of a service with service consumers, and the
sequence and dependencies of those interactions.
Views implementing this Viewpoint:
• Shall identify service is scope.
• Shall identify service consumers.
• Shall identify interactions of service consumers with the service.
• May show service operations, and sequence of service operations.
• May show service functions, and sequence of service functions.
CONCERNS ADDRESSED USAGE
• Detailed Service Specifications. • Service specification.
• Outline requirements for Service behaviour.
• Service implementation guidance.

REPRESENTATION
• Sequence Diagram.
 38 NAFv4@ArchiMate

17.1 S6 Objects [by NAF Layer]

# Service # Service # Service

Operation Operation Operation

# Business # Technology # Application

Service Service Service
Interface Interface Interface

# Business # Technology # Application

Service Service Service

# Equipment # Technology # Application

# Business Node
Node Node Node

# Business
# Technology # Application
Function
Function Function
# Interaction

# Role
 NAFv4@ArchiMate 39

17.2 S6 Implementation Guidance

Services, Service Interfaces, Service Functions and Service Operations exist at 3 layers within
ArchiMate. Where this layering is applicable to the architecture, this must be present in this
viewpoint.
Nodes exist at 4 ArchiMate layers, depending on their layer are represented by Business Actor,
Application Component, Technology Node and Equipment. Nodes realise Services.
Note that Service Operations also use the ArchiMate notation of Function. Whilst the Service
Function is assigned to a Node, a Service Operation is served by the Service Interface which is in turn
assigned to the Service.
A Business Role or a Service can interact with any other Service and/or Business Role, via an
association relation. Each Interaction has attributes to mark the start and end points of the
Interaction such that the ordering of the Interaction as part of sequence can be visualised
Visually this will be similar to a UML sequence diagram. The description here is for modelling
purposes only.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Service # Business Service Business service
Service Operation # Business Service Business service
Service Consumer # Role Business role
Node # Role Business role
Service # Technology Service Technology service
Service Operation # Technology Service Technology service
Service Operation # Application Service Application service
Service # Application Service Application service
Node # Business Node Business actor
Node # Technology Node Node
Node # Application Node Application component
Service Function # Business Function Business function
Service Function # Technology Function Technology function
Service Operation # Service Operation Technology function
Service Operation # Service Operation Business function
Interaction # Interaction Business interaction
Service Interface # Application Service Interface Application interface
Service Interface # Technology Service Interface Technology interface
Service Interface # Business Service Interface Business interface
Node # Equipment Node Equipment
Service Operation # Service Operation Application function
Service Function # Application Function Application function
 40 NAFv4@ArchiMate

18 S7 SERVICE I/F PARAMETERS

S7– Service Interface Parameters NAFv3: NSOV-2

The S7 Viewpoint is concerned with identification and specification of all the parameters used in service
operations.
Views implementing this Viewpoint:
• Shall identify parameters of service operations relevant for the architecture.
• May specify the data types of each parameter.
• May show the assignment of service operations to service interfaces.
CONCERNS ADDRESSED USAGE
• Detailed Service design. • Service-oriented architecture governance.
• Service compatibility analysis. • Detailed service specification.
• Service interoperability.

REPRESENTATION
• Tabular.
• Diagram.
 NAFv4@ArchiMate 41

18.1 S7 Objects [by NAF Layer]

# Business # Technology # Application

Service Service Service

# Business # Technology # Application

Service Service Service
Interface Interface Interface

# Service
Requirement

18.2 S7 Implementation Guidance

Services and Service Interfaces exist at 3 layers within ArchiMate. Where this layering is applicable to
the architecture, this must be present in this viewpoint.
Each Service may be assigned at least one Service Interface which shall realise a Service
Requirement via the parameters of the interface.
No Service Operation object is shown here since it is unclear if this is a discrete obhject or part of the
Service itself, the parameters themselves shoudl be modelled as attributes of the interface.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Service Operation # Application Service Application service
Service Interface # Technology Service Interface Technology interface
Service Operation # Technology Service Technology service
Constraint # Service Requirement Requirement
Service Interface # Business Service Interface Business interface
Service Interface # Application Service Interface Application interface
Service Operation # Business Service Business service
 42 NAFv4@ArchiMate

19 S8 - SERVICE POLICY

S8– Service Policy NAFv3: NSOV-4C

The S8 Viewpoint is concerned with the identification and description of rules that apply to service
implementations.
Views implementing this Viewpoint:
• Shall define constraints that shall apply for implementations of each service specifications relevant
for the architecture.
• May include measures for the service specifications.
• May include attributes for the service specifications.
CONCERNS ADDRESSED USAGE
• Service Specifications. • Service design.
• Contracting for Services. • Service governance.
• User / System Requirements.

REPRESENTATION
• Tabular.
• Diagram.
 NAFv4@ArchiMate 43

19.1 S8 Objects [by NAF Layer]

# Service Policy

# Service
Requirement

# Business # Application # Technology

Service Service Service

19.2 S8 Implementation Guidance

Services exist at 3 layers within ArchiMate. Where the layering of services is applicable to the
architecture, they must be present on the viewpoint.
The Service(s) shall realize a Service Policy [a defined set of requirements], represented as a
Requirement, itself being an aggregation of Service Requirement(s).

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Service Specification # Application Service Application service
Service # Application Service Application service
Service Specification # Technology Service Technology service
Service # Technology Service Technology service
Service Specification # Business Service Business service
Service # Business Service Business service
Constraint # Service Requirement Requirement
Service Policy # Service Policy Requirement
 44 NAFv4@ArchiMate

20 SR - SERVICE ROADMAP

Sr– Service Roadmap NAFv3: NONE

The Sr Viewpoint is concerned with the identification and description of life cycle information of service
specifications.
Views implementing this Viewpoint:
• Shall identify service specifications related to the roadmap
• Shall define start and end date of service specification support.
• May identify programmes or projects associated with the service specification delivery/withdrawal.
• May identify service levels.
• May identify service attributes.
• May associate measures to service attributes.
CONCERNS ADDRESSED USAGE
• Service Life Cycle Planning. • Service phasing.
• Acquisition Management. • Service gap/surplus analysis.
• High-level dashboard for acquisition
management.

REPRESENTATION
• A time based chart in the style of a Gantt chart.
• Tabular.
 NAFv4@ArchiMate 45

20.1 Sr Objects [by NAF Layer]

# Service
Roadmap

# Business # Technology # Application

Service Service Service

20.2 Sr Implementation Guidance

Services exist at 3 layers within ArchiMate. Where the layering of services is applicable to the
architecture, they must be present on the viewpoint.
The Service Roadmap is the roadmap canvas on which the Service is laid out as a Gantt chart,
represented here as a Plateau.
Each Service has an attribute for start and end data for the readiness level appropriate to the Service.
Visually this will be similar to a Gantt chart. The description here is for modelling purposes only.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Service Specification # Business Service Business service
Service Specification # Technology Service Technology service
Service Roadmap # Service Roadmap Plateau
Service Specification # Application Service Application service
 46 NAFv4@ArchiMate

21 C1-S1 SERVICE TO CAPABILITY MAPPING

C1-S1 – Capability to Service Mapping NAFv3: NSOV-3

The C1-S1 Viewpoint is concerned with identification and description of services that enable
capabilities. Views implementing this Viewpoint:
• Shall contain service specifications relevant for the architecture.
• Shall contain capabilities relevant for the architecture.
• Shall associate services to capabilities they enable.
CONCERNS ADDRESSED USAGE
• Mapping of capabilities to services that they are • Service Specification & Planning.
supported by. • Governance.

REPRESENTATION
• Matrix (with capabilities on one axis, and services on the other one).
• Diagram.
 NAFv4@ArchiMate 47

21.1 C1-S1 Objects [by NAF Layer]

# Capability

# Business
Service

# Application
Service

# Technology
Service

21.2 C1-S1 Implementation Guidance

Services exist at 3 layers within ArchiMate. Where the layering of services is applicable to the
architecture, they must be present on the viewpoint.
Services realize a Capability.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Service Specification # Application Service Application service
Service # Application Service Application service
Capability # Capability Capability
Service Specification # Business Service Business service
Service # Business Service Business service
Service Specification # Technology Service Technology service
Service # Technology Service Technology service
 48 NAFv4@ArchiMate

22 LOGICAL GLOSSARY

22.1 Logical Layer Glossary

NAFv4 ArchiMate Name ArchiMate Name Description

# Technology Node Node The logical class of Active Resource of type
Technology. e.g Network Switch, Server
# Logical Business Business event A functional condition of an Business Node
Operational State at a point in time. There is no natural
mapping of an ArchiMate element to a
State. However, states are linked to events
in that an event needs to occur to move
from one state to another
# Logical Location Location The place a logical element [can] exist[s]. A
hospital, a field
# Business Node Business actor The logical class of Active Resource of type
Business. e.g Company, Battalion, Team
# Operational Activity Business process An element of logical behaviour, specified
independently of how it is carried out
# Logical Technology Technology event A functional condition of an Technology or
Operational State Equipment Node at a point in time.
Example: the state of software might be
out of date. There is no natural mapping of
an ArchiMate element to a State. However,
states are linked to events in that an event
needs to occur to move from one state to
another
# Role Business role The responsibilities and characteristics of a
Node
# Interaction Business interaction An [Interaction] between two or more
Services or Active Resources at the Service
or Logical Layer, conveying Passive or Data
Resources
# Application Node Application The logical class of Active Resource of type
component Application. e.g CRM System, ERP System
# Logical Requirement Requirement A constraint specified at the service level
# Equipment Node Equipment The logical class of Active Resource of type
Equipment. e.g Tent, Helicopter, Jet Plane
# Standard Operational Business process An [Operational Activity] that is a standard
Activity procedure specified by policies (e.g.
doctrine).
# Information Element Data object An identified unit or piece of Knowledge
that is exchangeable amongst users, about
things, facts, concepts, and so on, in a
universe of discourse
# Logical Application Application event A functional condition of an Application
Operational State Node at a point in time. Example: the state
of an application could be unstable. There
 NAFv4@ArchiMate 49

is no natural mapping of an ArchiMate

element to a State. However, states are
linked to events in that an event needs to
occur to move from one state to another
# Business Function Business function An internal behavioural 'Feature' of a
Business Node
# Information Attribute Requirement A representation of a property of an
[Information Entity].
# Event Business event An external trigger to start a [sequence of]
Interaction[s] at the logical level. Example:
Casualty at the point of injury.
# Logical Material Material A Passive Reource that may be produced,
consumed or conveyed at the logical layer
# Application Function Application function An internal behavioural 'Feature' of an
Application Node
# Technology Function Technology function An internal behavioural 'Feature' of a
Technology Node
# MoP Requirement Type of measurement specifically of
Perfomance [of a Node]
 50 NAFv4@ArchiMate

23 L1 - NODE TYPES

L1– Node Types NAFv3: NOV-2

The L1 Viewpoint is concerned with the identification of nodes, and their organization into specialization
hierarchies (taxonomies). In the NAF, nodes are logical entities (i.e. defined independent of their
implementation) that are able to perform behaviour.
Views implementing this Viewpoint:
• Shall identify all nodes relevant for the architecture.
• May show a specialization hierarchy for nodes.
• May trace nodes to capabilities they need.
• May trace nodes to roles they are performing in activities.
• May include Measures of Performance (MoP).
A node taxonomy, in whole or parts, may be referenced by, or used in describing, multiple architectures
(e.g. a L1 View at enterprise-level will be referenced by L1 Views at the capability-level).
CONCERNS ADDRESSED USAGE
• User Requirements. • Initial set up of a Logical Architecture.
• Operational Planning. • Defining MoP for requirements specification
• High-Level Systems Requirements. purposes.
• Defining the types of environment in which
Nodes may operate.

REPRESENTATION
• Topological (connected shapes).
• Tabular.
 NAFv4@ArchiMate 51

23.1 L1 Objects [by NAF Layer]

# Operational
# Role
Activity

# Application # Technology # Equipment

# Business Node
Node Node Node

# MoP

# Capability

23.2 L1 Implementation Guidance

Nodes exist at 4 ArchiMate layers, depending on their layer are represented by Business Actor,
Application Component, Technology Node and Equipment
Active Resources at the logical layer are either a Business Role or Nodes. Any Active Resource can be
a specialization of its own Node type. Nodes are associated with Business Roles due to ArchiMate
not being able to assign Business Role to non-business layer objects.
A Business Role is assigned to an Operational Activity.
Nodes may be associated with a Capability when they are dependent on it, and Business Role to
represent their 'usage' in the Operational Activity.
All Active Resources have an MoP (Measure of Performance), represented as Requirements. MoP is a
specialization of Measurement.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Node # Equipment Node Equipment
Node # Technology Node Node
Node # Business Node Business actor
Node # Application Node Application component
Capability # Capability Capability
OperationalActivity # Operational Activity Business process
Node # Role Business role
 52 NAFv4@ArchiMate

24 L2 - LOGICAL SCENARIO

L2 – Logical Scenario NAFv3: NOV-2

The L2 Viewpoint is concerned with identifying key or aggregated interactions between nodes. Views
implementing this Viewpoint:
• Shall include nodes relevant for the architecture.
• Shall define logical flows (e.g. logical flow of information) independent of their implementation.
• Shall only include key individual and/or aggregated logical flows between nodes.
• May include a mapping of nodes to locations.
CONCERNS ADDRESSED USAGE
• User Requirements. • Definition of operational concepts.
• Operational Planning. • Elaboration of capability requirements.
• Scenario Specification. • Definition of collaboration needs.
• Associating capability with a location.
• Problem space definition.
• Operational planning.
• Supply chain analysis.
The L2 Viewpoint can be enhanced with
additional features for modelling security:
• Security domain specification.
• Logical entity trust models.
• Threat specification (e.g. threat vectors) and
counter-capability specifications.
REPRESENTATION
• Topological (connected shapes).
• Composite structure diagram.
 NAFv4@ArchiMate 53

24.1 L2 Objects [by NAF Layer]

# Logical Location

# Application # Technology # Equipment

# Business Node
Node Node Node

24.2 L2 Implementation Guidance

Nodes exist at 4 ArchiMate layers, depending on their layer are represented by Business Actor,
Application Component, Technology Node and Equipment
Active Resources at the logical layer are either a Business Role or Node. Each Node can be composed
of other Nodes, of the same type. Nodes may also be aggregated by a Logical Location Flow relations
represent flow of information between Nodes (as Active Resources) of any type as part of the
scenario.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Node # Application Node Application component
Node # Equipment Node Equipment
Logical Location # Logical Location Location
Node # Technology Node Node
Node # Business Node Business actor
 54 NAFv4@ArchiMate

25 L2-L3 - LOGICAL CONCEPT

L2-L3 – Logical Concept NAFv3: NOV-1

The L2-L3 Viewpoint is concerned with providing an executive level, scenario-based communication of
the architecture purpose, scope and content.
A View implementing this Viewpoint:
• Shall show the main elements in scope of the Architecture Description.
• Shall show the main interactions of these elements.
• May show interactions of the main elements with elements outside the scope.
• May include any meta-model element.
• May include rich picture or graphics.
CONCERNS ADDRESSED USAGE
• High-Level Communication of Architecture. • Puts an operational situation or scenario into
• Senior Stakeholder Engagement. context.
• Provides a tool for discussion and
presentation; e.g. aids industry engagement
in acquisition.
• Provides an overview of more detailed
information in published architectures.

REPRESENTATION
• Graphic.
• Rich Picture.
• Concept diagram.
• Project context diagram.
 NAFv4@ArchiMate 55

25.1 L2-L3 Objects [by NAF Layer]

# Application # Technology # Equipment

# Business Node
Node Node Node

# Interaction

25.2 L2-L3 Implementation Guidance

Nodes exist at 4 ArchiMate layers, depending on their layer are represented by Business Actor,
Application Component, Technology Node and Equipment.
Business Interactions are associated with flow relations between Nodes for modelling purposes only.
Visually this will be a rich picture containing only Nodes and flows.
Each Interaction may have attributes that define its properties.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Node # Application Node Application component
Node # Business Node Business actor
Node # Equipment Node Equipment
Logical Flow # Interaction Business interaction
Interaction # Interaction Business interaction
Node # Technology Node Node
 56 NAFv4@ArchiMate

26 L3 - NODE INTERACTIONS

L3 – Node Interactions NAFv3: NOV-2, 3

The L3 Viewpoint is concerned with identifying all relevant interactions between nodes. Views
implementing this Viewpoint:
• Shall include nodes relevant for the architecture.
• Shall include all logical flows (e.g. logical flow of information) between nodes relevant to the
architecture.
• Shall define logical flows independent of their implementation.
• May associate the logical flows to logical activities.
• May define properties of the logical flows.
• May define measure of the logical flows.
CONCERNS ADDRESSED USAGE
• Interoperability Requirements. • Definition of interoperability requirements.

REPRESENTATION
• Tabulation.
• Information flow diagram.
 NAFv4@ArchiMate 57

26.1 L3 Objects [by NAF Layer]

# Operational
Activity

# Information
# Logical Material
Element

# Application # Technology # Equipment

# Business Node
Node Node Node

# Interaction

26.2 L3 Implementation Guidance

Nodes exist at 4 ArchiMate layers, depending on their layer are represented by Business Actor,
Application Component, Technology Node and Equipment
Business Interactions are associated with Nodes and the flow relations between them, they access
both Material and Information Elements, as Data Objects during the Interaction.
Attribites may be added to Interactions to describe their properties with association relations
between Passive Resources and flows as part of the Interaction, which is in turn associated with the
flow relation
This viewpoint also visualises how the Interaction serves the Operational Activity.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Node # Equipment Node Equipment
Logical Activity # Operational Activity Business process
Node # Application Node Application component
Node # Technology Node Node
Logical Flow # Interaction Business interaction
Node # Business Node Business actor
 58 NAFv4@ArchiMate

27 L4 - LOGICAL ACTIVITIES

L4 – Logical Activities NAFv3: NOV-5

The L4 Viewpoint is concerned with the identification of logical (i.e. implementation independent)
activities, grouping and composition of these activities, and logical flows between the activities.
Views implementing this Viewpoint:
• Shall identify logical activities relevant for the architecture.
• May identify groupings of activities.
• May identify composition of activities.
• May associate logical activities to nodes.
• May identify logical flows between activities.
CONCERNS ADDRESSED USAGE
• Process Modelling. • Requirements capture.
• Operational Planning. • Description of business processes and
• Concept of Operations. workflows.
• Service Orchestration. • Operational planning.
• Logistics support analysis.
• Information flow analysis.
• Support task analysis to determine training
needs.
REPRESENTATION
• Hierarchy chart.
• Activity diagram.
• Collaboration Diagram.
 NAFv4@ArchiMate 59

27.1 L4 Objects [by NAF Layer]

# Logical Material

# Information
Element

# Operational
# Role
Activity

# Application # Technology # Equipment

# Business Node
Node Node Node

27.2 L4 Implementation Guidance

Nodes exist at 4 ArchiMate layers, depending on their layer are represented by Business Actor,
Application Component, Technology Node and Equipment
One or more Nodes play a part in performing an Operational Activity via a serving relation through
the conveyance of Material and/or Information Elements, as Data Objects.
Roles are assigned to the Operational Activity and represent the 'swimlane' in a process/activity
diagram.
Grouping of Operational Activities is shown via a composition relation. A triggering relation is used
to represent the logical flow between activites.
The specific flows between nodes are not shown here since they are adequately covered in L2 and
L3.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Node # Business Node Business actor
Logical Activity # Operational Activity Business process
Node # Application Node Application component
Node # Equipment Node Equipment
Node # Role Business role
Node # Technology Node Node
 60 NAFv4@ArchiMate

28 L5 - LOGICAL STATES

L5 – Logical States NAFv3: NOV-6b

The L5 Viewpoint is concerned with the identification and definition of the possible states a node may
have, and the possible transitions between those states.
Views implementing this Viewpoint:
• Shall identify and define all states of a node relevant for the architecture.
• May describe possible state transitions.
CONCERNS ADDRESSED USAGE
• Scenario Specification. • Analysis of business events.
• User Requirements Specification. • Behavioural analysis.
• Identification of constraints.

REPRESENTATION
• Topological (Connected Shapes).
• State diagram.
 NAFv4@ArchiMate 61

28.1 L5 Objects [by NAF Layer]

# Logical
# Business Node Business
Operational State

# Logical
# Application Application
Node Operational State

# Technology
Node

# Logical
Technology
Operational State

# Equipment
Node

28.2 L5 Implementation Guidance

Nodes exist at 4 ArchiMate layers, depending on their layer are represented by Business Actor,
Application Component, Technology Node and Equipment.
Each Node has assigned one or more Operational States that correspond to the ArchiMate Layer of
the relevant Node. Triggering relations between the Operational States show State Transitions of
the Node during operation
Operational States are the same as at the NAFv4 Service layer since Nodes should not have a
different Operational State than the Service they realize.
62 NAFv4@ArchiMate

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

State # Logical Technology Operational State Technology event
OperationalStateDescription # Logical Technology Operational State Technology event
Node # Business Node Business actor
State # Logical Application Operational State Application event
OperationalStateDescription # Logical Application Operational State Application event
Node # Equipment Node Equipment
Node # Technology Node Node
State # Logical Business Operational State Business event
OperationalStateDescription # Logical Business Operational State Business event
Node # Application Node Application component
 NAFv4@ArchiMate 63

29 L6 LOGICAL SEQUENCE

L6 – Logical Sequence NAFv3: NOV-6c

The L6 Viewpoint is concerned with identifying and describing the chronological sequence of activities
and/or logical flows in a scenario.
Views implementing this Viewpoint:
• Shall identify the activities and/or logical flows relevant for a scenario.
• Shall identify the chronological sequence of activities and/or logical flows.
• May identify source and target nodes of logical flows
• May identify start and end events of a sequence.
CONCERNS ADDRESSED USAGE
• Operational Planning. • Analysis of operational events.
• User Requirements Specification. • Sequences of interactions between nodes.
• Service Orchestration. • Behavioural analysis.
• Identification of non-functional user
requirements.
• Operational test scenarios.
REPRESENTATION
• Sequence diagram.
• Event-trace diagram.
• Timing diagram.
 64 NAFv4@ArchiMate

29.1 L6 Objects [by NAF Layer]

# Standard
# Operational
Operational
Activity
Activity

# Application # Technology # Equipment

# Business Node
Node Node Node

# Interaction

# Event

29.2 L6 Implementation Guidance

Nodes exist at 4 ArchiMate layers, depending on their layer are represented by Business Actor,
Application Component, Technology Node and Equipment.
Any Node can interact with any other Node, via an association relation with a Business Interaction
the same Interaction as at the NAFv4 Service layer.
Each Interaction has attributes, not visualised here, that mark the start and end points of an
Interaction in a sequence. The external Event that triggers the initial Interaction, as part of the
sequence, is also shown as well as triggering relations between Interactions as part of the sequence.
The viewpoint also describes the part in the Operational Activity that the Interaction plays via a
serves relation.
Visually this will be similar to a UML sequence diagram. The description here is for modelling
purposes only.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Standard Operation Activity # Standard Operational Activity Business process
Node # Application Node Application component
Node # Technology Node Node
Node # Business Node Business actor
Logical Flow # Interaction Business interaction
Logical Activity # Operational Activity Business process
Node # Equipment Node Equipment
Event # Event Business event
 NAFv4@ArchiMate 65

30 L7 - INFORMATION MODEL

L7 – Information Model NAFv3: NOV-7

The L7 Viewpoint is concerned with identifying information elements, and describing their relationships.
Views implementing this Viewpoint:
• Shall identify information elements relevant for the architecture.
• May identify relationships between information elements.
• May identify attributes of information elements.
• May associate attributes with data entities.
CONCERNS ADDRESSED USAGE
• Information Requirements. • Information architecture.
• Message Requirements. • Information product hierarchy.
• Information Models.

REPRESENTATION
• Entity-Relationship diagram.
• Class diagram.
 66 NAFv4@ArchiMate

30.1 L7 Objects [by NAF Layer]

# Information
# Data Entity
Element

# Information
# Data Attribute
Attribute

30.2 L7 Implementation Guidance

How Information Elements are related to each other, either hierarchically (specialization) or with
other Information Elements (association) are shown in this viewpoint, alongside their Information
Attributes, represented here as a Business Objects
How Data Entities realize the Information Element are also optionally described, as well as the Data
Attributes of the Data Entity as appropriate, whilst these are not expected to be modelled visually
they are present here, as Requirements for completeness.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Data Element # Data Entity Artifact
Data Entity # Data Entity Artifact
Attribute # Data Attribute Requirement
Attribute # Information Attribute Requirement
Information Element # Information Element Data object
 NAFv4@ArchiMate 67

31 L8 - LOGICAL CONSTRAINTS

L8 – Logical Constraints NAFv3: NOV-6A

The L8 Viewpoint is concerned with identification and description of operational or business rules.
Views implementing this Viewpoint:
• Shall identify operational or business rules relevant for the architecture.
• Shall assign these rules to nodes, activities and/or logical flows.

CONCERNS ADDRESSED USAGE

• User Requirements Specification (Non-Functional). • Definition of business rules.
• Operational Constraints. • Identification of operational constraints.

REPRESENTATION
• Structured Text.
• Business rules diagram.
 68 NAFv4@ArchiMate

31.1 L8 Objects [by NAF Layer]

# Logical
Requirement

# Technology # Equipment # Application # Operational

# Business Node # Interaction
Node Node Node Activity

31.2 L8 Implementation Guidance

Nodes exist at 4 ArchiMate layers, depending on their layer are represented by Business Actor,
Application Component, Technology Node and Equipment.
All Active Resources, Operational Activities (Business Process) and Business Interactions can realize
a Logical Requirement.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Node # Business Node Business actor
Operational Constraints # Logical Requirement Requirement
Rule # Logical Requirement Requirement
Node # Application Node Application component
OperationalActivity # Operational Activity Business process
Logical Flow # Interaction Business interaction
Node # Equipment Node Equipment
Node # Technology Node Node
 NAFv4@ArchiMate 69

32 LR - LINES OF DEVEOPMENT

Lr – Lines of Development NAFv3: NPV-2

The Lr Viewpoint is concerned with identifying and defining logical threads (lines of developments) for a
set of projects and/or programmes.
Views implementing this Viewpoint:
• Shall identify project deliverables (e.g. capability increments, services or resource packages).
• Shall associate project deliverables to project milestones.
• May show states of deliverables at project milestones.
• May associate project deliverables to enterprise phases.
• May show project milestone dependencies.
CONCERNS ADDRESSED USAGE
• Acquisition Planning. • Project management and control (including
• Portfolio / Programme Management. delivery timescales).
• Project Performance Reporting / Dash boarding. • Project dependencies and the identification
of associated risk.
• Portfolio management.
• Through Life Management Planning.

REPRESENTATION
• Timeline View.
• Augmented chart in style of a Gantt Chart.
 70 NAFv4@ArchiMate

32.1 Lr Objects [by NAF Layer]

# Enterprise
# Work Package # Capability
Phase

# Equipment # Technology # Application

# Business Node
Node Node Node

32.2 Lr Implementation Guidance

Nodes exist at 4 ArchiMate layers, depending on their layer are represented by Business Actor,
Application Component, Technology Node and Equipment. The evolution of these nodes is modelled
as start and end dates as attributes of the Nodes that can subsequently be related to the Enterprise
Phase via the Capability Increment.
The roadmap is the canvas on which the Capability Increment as a specialization of Capbility (C1) is
laid out as a Gantt chart, represented here as the Enterprise Phase Plateau.
Visually this will be similar to a Gantt chart. The description here is for modelling purposes only.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Node # Business Node Business actor
Capability Increment # Capability Capability
Node # Equipment Node Equipment
EnterprisePhase # Enterprise Phase Plateau
Node # Technology Node Node
Project # Work Package Work package
Program # Work Package Work package
Node # Application Node Application component
 NAFv4@ArchiMate 71

33 PHYSICAL GLOSSARY

33.1 Physical Layer Glossary

In ArchiMate a Business Actor cannot be assigned to a.n.other Business Actor. For this reason a
Business Role has been used to represent a NAFv4 Post. Whilst this may cause consternation in
some camps it is proposed here as the best option for this guidance.

NAFv4 ArchiMate Name ArchiMate Name Description

# Trigger Application event An external Application trigger to start a
[sequence of] Resource Interaction[s] at
the Physical level.
# Data Model Artifact A [Model] describing the [Data] referring to
a specific Application Domain. Note: An
Data Model typically describes the
structure of the [Data] in terms of entities,
relationships and their attributes.
# Path Path A mechanism for conveyance of [Data]
between Active Resources, can be used to
prepresent the pathway for an actual
Resource Interaction
# Trigger Technology event An external Technological trigger to start a
[sequence of] Resource Interaction[s] at
the Physical level.
# Technology Resource Technology event A [State] specified for a [Resource].
State Example: an application could be
unavailable.
# Person Business actor An Actual Person. An identifiable instance
of a Person Type. Example: Goalkeeper of
the BSC Young Boys, Rowan Atkinson.
# Technology Resource Node Any one of; Technology Concept A
[Technology] specified at the conceptual
level. Technology Class A set of
[Technology]s that are linked to a
particular application domain. Examples:
medical technologies, mechanical
technologies, information technology, etc.
# Application Resource Application event A [State] specified for an Application
State Resource Example: an application could be
unavailable.
# Capability Configuration Grouping A solution building block that combines
physical resources (people, technology)
and implements processes to realize a
[Capability].
72 NAFv4@ArchiMate

# Business Resource Business function One or more expected behaviour(s), or

Function skills, as features of an Organisation or
Person
# Trigger Business event An external Business trigger to start a
[sequence of] Resource Interaction[s] at
the Physical level.
# Business Resource State Business event A [State] specified for an Business
Resource
# Application Resource Application function One or more expected behaviour(s), as
Function features of an Application
# Data Entity Artifact An identified unit or piece of digital or
analogue representation of [Information]
which is stored in or transferred via a
medium. Note: a language is a logical
medium while a piece of paper is a physical
medium
# Post Business role An actual Post. An identifiable instance of a
role. Examples: The Pilot of the helicopter
crew
# Technology Resource Technology function One or more expected behaviour(s), as
Function features of Equipment or Technology
# Organisation Business actor An Actual instantiation of a Business Node.
e.g specific Company, Regiment
# Resource Rationale Principle A [Rationale] that is applied at the resource
level.
# Data Attribute Requirement A representation of a property of a [Data
Entity].
# Energy Material A concrete and deliverable instance of
energy. Examples: Red Diesel, AC 220V
50Hz.
# Equipment Resource Equipment An identifiable instance of an [Equipment
Node] at the logical level. Example: The
Challenger tank with the plate number H-
235.
# Protocol Artifact A kind of [Standard] specifying how two
entities communicate or interact with each
other. {NAF4IM}
# Resource Requirement Requirement A [Constraint] specified at the resource
level. Functional and non-functional
[Requirement]s describing a system.
Example: the requirements expressed in a
System Requirements Document (SRD).
# Application Application An actual Application as an instantiation of
component a logical Application Node e.g Dynamics
# Distribution network Distribution network A mechanism for conveyance of Passive
Resources between Active Resources, Can
be used to prepresent the pathway for an
actual Resource Interaction
# Resource Interaction Technology A [Resource Interaction] between two or
interaction more Active Resources at the physical
layer, conveying Passive or Data Resources
 NAFv4@ArchiMate 73

# Data Product Artifact An item that is elaborated from one or

more sources of [Data] to meet a specific
purpose. Note: quality assurance aspects
are frequently associated to a Data Product
which is delivered to a decision maker (e.g.
integrity and credibility).
# Material Material A concrete and tangible piece of material.
Examples: Monkey 47 (Gin), HP Inkjet
Cartridge Type 305, Inconel-718+ (nickel
alloy).
 74 NAFv4@ArchiMate

34 P1 - RESOURCE TYPES

P1 - Resource Types NAFv3: NAV-2/NCV-3/NSV-2A, 7, 9, 12

The P1 Viewpoint is concerned with specification of the types of resources and identifying required
technologies and competences.
Views implementing this Viewpoint:
• Shall include all Resource Types relevant for the architecture together with a depiction of their
performance characteristics.
• Shall describe the interface protocols and hardware specifications of each port on a system and
include properties of Resource ports exposed by technical resources.
• Shall map the described Resource Types back to the Capabilities and/or Services they implement
(without specifying these Services themselves).
• Shall provide a summary of the technologies and competences that impact on the Resources
constituting the architecture.
• Shall specify Service Levels for the implemented Services and for other Services (effectively a
composition of services) required for their implementation.
• May include descriptions of relevant emerging and current technologies, industry trends, predictions
of the availability and readiness of specific hardware/software products, current and possible future
skills.
• May organize the Resources into a specialization hierarchy.
• May give forecasts of relevant technologies and competences in short, mid and long-term
timeframes and include an assessment of the potential impact of the forecast items on the
enterprise.
CONCERNS ADDRESSED USAGE
• Capability Delivery. • Identifying Resource Taxonomies.
• Service Implementation. • Interface specification.
• Interface Specification. • Identification of applicable protocols.
• Service implementation.
• Tracing business processes to the resources
that support them.
• Forecasting technology readiness against
time.
• HR trends analysis.
• Recruitment planning.
• Planning technology insertion.
• Input to options analysis.
• Definition of performance characteristics.
• Identification of non-functional
requirements.
REPRESENTATION
 NAFv4@ArchiMate 75

• Tabular.
• Mapping (matrix).
• Topological – connected shapes.
• Composite Structure Diagram.
• Block diagram.
• Timeline View.
• Herringbone style diagram.

34.1 P1 Objects [by NAF Layer]

# Capability

# Business # Technology # Application

Service Service Service

# Equipment # Technology
# Post # Person # Organisation # Application
Resource Resource

# Data Product # Material # Energy

# Business # Technology # Application

Resource Resource Resource
Function Function Function

34.2 P1 Implementation Guidance

Nodes and Resources exist at any of 4 ArchiMate layers, and depending on their layer are
represented by Business Actor, Application Component, Technology Node and Equipment.
Active Resources at the Physical layer are assigned to the Resource Functions in their own ArchiMate
layer and are the actual Active Resources that realize a Capability, and/or a Service also in their own
ArchiMate layer
Resource Functions exist at 3 layers within ArchiMate, they can access (deliver) a Data Product,
represented as an Artefact, but only Resource Functions in the ArchiMate Technology layer can
access Actual Material or Energy (also represented as Material).
Interface Protocols and System Ports are omitted from this viewpoint.
76 NAFv4@ArchiMate

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Service # Business Service Business service
Resource # Post Business role
Resource # Material Material
Resource # Energy Material
Resource # Equipment Resource Equipment
Resource # Person Business actor
CapabilityConfiguration # Capability Capability
Capability # Capability Capability
Service # Technology Service Technology service
Resource # Application Application component
Competence # Business Resource Function Business function
Resource # Technology Resource Node
Resource # Organisation Business actor
Competence # Application Resource Function Application function
Competence # Technology Resource Function Technology function
Resource # Data Product Artifact
Service # Application Service Application service
 NAFv4@ArchiMate 77

35 P2 - RESOURCE STRUCTURE

P2 – Resource Structure NAFv3: NSV-1/NOV-4

The P2 Viewpoint is concerned with the composition and (high-level) interaction of resources. Views
implementing this Viewpoint:
• Shall link together the operational and physical Architecture Views by depicting how types of
Resource are structured and interact to realize the logical architecture specified in L2, Logical
Scenario.
• Shall describe the structure of resources, decomposed to any suitable level, by identifying the
primary sub-systems, posts/roles and their interactions (e.g., data, materiel, human resources,
energy).
• Shall gather systems meeting a specific capability as Capability Configurations.
• May represent the realisation of a requirement specified in a L2, maybe as several alternative
Resource Views suites which could realize the operational requirement.
• May specify typical (or template) organizational structures, and also identify how human resources
interact with each other and with systems.
• May identify the artefacts upon which resources are deployed and can show the nodes that the
resources realize.
CONCERNS ADDRESSED USAGE
• Physical Architecture. • Definition of system concepts.
• Systems Engineering / Design. • Definition of system options.
• Organizational Design. • Human – System interactions.
• Systems Integration. • Typical Organization structures.
• System Requirements Specification. • Interface requirements capture.
• Capability integration planning.
• System integration management.
• Operational planning (capability
configuration definition).

REPRESENTATION
• Topological (connected shapes).
• Composite structure diagram.
• Block diagram.
 78 NAFv4@ArchiMate

35.1 P2 Objects [by NAF Layer]

# Technology # Equipment # Application # Logical

# Role # Business Node
Node Node Node Requirement

# Capability
Configuration

# Resource
Rationale

# Technology # Equipment
# Post # Person # Organisation # Application # Energy # Material # Data Product
Resource Resource

# Resource
Requirement

35.2 P2 Implementation Guidance

Nodes and Resources exist at any of 4 ArchiMate layers, and depending on their layer are
represented by Business Actor, Application Component, Technology Node and Equipment.
Active Resources at the Physical layer are assigned to the Resource Functions in their own ArchiMate
layer and are the actual Active Resources that realize a Capability, and/or a Service also in their own
ArchiMate layer they also specialize their equivalent Active Resources (Nodes) at the Logical layer
Active Resources are associated with Resource Interaction either as the originator or the terminator
of a specific Resource Interaction, whilst Passive Resources (Material) and Data Resources
(Artefacts) are accessed (conveyed) during the Resource Interaction.
A Capability Configuration aggregates Active Resources and/or Data Resources and/or Passive
Resources in any combination.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Node # Application Node Application component
Resource # Application Application component
Subsystem # Application Application component
Node # Technology Node Node
Node # Business Node Business actor
Energy # Energy Material
Resource # Energy Material
Resource # Data Product Artifact
Data # Data Product Artifact
Subsystem # Person Business actor
Resource # Person Business actor
Human Resources # Person Business actor
Resource # Equipment Resource Equipment
Subsystem # Equipment Resource Equipment
Subsystem # Technology Resource Node
Resource # Technology Resource Node
Subsystem # Organisation Business actor
Resource # Organisation Business actor
Operational Requirement # Resource Requirement Requirement
 NAFv4@ArchiMate 79

Node # Role Business role

CapabilityConfiguration # Capability Configuration Grouping
Node # Equipment Node Equipment
Operational Constraints # Logical Requirement Requirement
Post # Post Business role
Resource # Post Business role
Resource # Material Material
 80 NAFv4@ArchiMate

36 P3 - RESOURCE CONNECTIVITY

P3 – Resource Connectivity NAFv3: NSV-2B, 2C, 6

The P3 Viewpoint is concerned with communication networks and pathways that link communications
systems, details regarding their configuration and characteristics of the data exchanged between
systems. Views implementing this Viewpoint:
• Shall represent the physical implementation of the logical flows (L2, Logical Scenario, or L3, Node
Interactions View) by specifying how systems are connected.
• Shall provide more technical detail than P2, including the protocols (specified in the P1 View)
implemented by systems and used by the connections between those systems.
• Shall focus on the physical characteristics of each link by specifying attributes (e.g., geographic
location, layout of network components such as routers, switches, amplifiers and repeaters).
• Shall include capacities (e.g. bandwidth, throughput), frequencies used, security encryption methods
used and other descriptive information as attributes.
• Shall only feature physical architectures, software and artefacts (as systems) and no organizational
resources.
• Shall show flows (as data elements relating to the P4, Resource Function Viewpoint) across system
boundaries and no internal flows which so not correspond to system port connections.
CONCERNS ADDRESSED USAGE
• Interface Specification. • Interface specification.
• Systems Engineering. • Identification of applicable protocols.
• System Requirements. • Description of system communication paths.
• Bandwidth and capacity analysis.
• Detailed definition of data flows.

REPRESENTATION
• Topological (connected shapes).
• Composite structure diagram.
• Structural diagram.
• Tabular.
 NAFv4@ArchiMate 81

36.1 P3 Objects [by NAF Layer]

# Resource
# Protocol
Interaction

# Technology # Equipment
# Application
Resource Resource

# Data Product # Energy # Material

# Path # Distribution network

# Data Entity

36.2 P3 Implementation Guidance

Resources exist at any of 4 ArchiMate layers, and depending on their layer are represented by
Business Actor, Application Component, Technology Node and Equipment.
Non-organizational Active Resources at the physical layer are associated with a Protocol to enable
inter resource communication or transport. Protocols are represented using an Artefact.
These Active Resources access (depend on) Passive Resources and/or Data Resources which as an
implementation of a Resource Interaction are accessed over an Distribution Network (Energy or
Material) or Path (Data Product or Data Entity).
Data Entities are associated with specific attributes (Properties and Characteristics). Other attributes
may be added as necessary to any of the objects within the viewpoint (e.g locations, capacities,
frequencies, encryption methods etc).

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Protocol # Protocol Artifact
Data Element # Data Entity Artifact
[derived from] Data Architecture # Data Product Artifact
Data Element # Data Product Artifact
System # Equipment Resource Equipment
82 NAFv4@ArchiMate

System # Technology Resource Node

Energy # Energy Material
Flow # Resource Interaction Technology interaction
System # Application Application component
 NAFv4@ArchiMate 83

37 P4 - RESOURCE FUNCTIONS

P4 – Resource Functions NAFv3: NSV-4

The P4 Viewpoint is concerning the Resource Functions carried out by all types of Resource (human and
non-human), including organizational resources.
Views implementing this Viewpoint:
• Shall specify the functionality of resources in the architecture as the functional counterpart to the
structures specified in the P2, Resource Structure Views.
• Shall include detailed information regarding the allocation of functions to resources, and the flow of
data between Resource Functions as the Physical Resource counterpart to the L4, Logical Activities
Views.
• Shall describe implementation-specific realisations of the operational activities specified in the L4,
Logical Activities Viewpoint.
• Shall include the complete functional connectivity (i.e. a resource’s required inputs are all satisfied).
CONCERNS ADDRESSED USAGE
• Capability-Based Acquisition. • Description of task workflow.
• Business Process Modelling. • Identification of functional system
• Workflow Modelling. requirements.
• Human-Machine Interaction Specifications. • Functional decomposition of systems.
• Relate human and system functions.

REPRESENTATION
• Topological (connected shapes).
• Activity diagram.
• Collaboration diagram (with swim lanes to represent resources).
• Functional Breakdown (decomposition).
 84 NAFv4@ArchiMate

37.1 P4 Objects [by NAF Layer]

# Operational
Activity

# Technology # Application
# Business
Resource Resource
Resource
Function Function
Function

# Person

# Technology # Equipment
# Post # Organisation # Application
Resource Resource

# Resource Interaction

# Material # Energy # Data Product

37.2 P4 Implementation Guidance

Resources exist at any of 4 ArchiMate layers, and depending on their layer are represented by
Business Actor, Application Component, Technology Node and Equipment.
Active Resources at the Physical layer are assigned to the Resource Functions in their own ArchiMate
layer, they serve an Operational Activity (Business Process).
Resource Functions are associated with a Resource Interaction which accesses (conveys) any or all of
a Data Product, Actual Material or Energy.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Function # Technology Resource Function Technology function
Resource Function # Technology Resource Function Technology function
Resource # Material Material
Resource # Person Business actor
Resource # Organisation Business actor
Data # Data Product Artifact
Resource # Data Product Artifact
OperationalActivity # Operational Activity Business process
Resource # Application Application component
Function # Application Resource Function Application function
Resource Function # Application Resource Function Application function
Function # Business Resource Function Business function
Resource Function # Business Resource Function Business function
 NAFv4@ArchiMate 85

Flow # Resource Interaction Technology interaction

Resource # Post Business role
Resource # Equipment Resource Equipment
Resource # Technology Resource Node
Energy # Energy Material
Resource # Energy Material
 86 NAFv4@ArchiMate

38 L4-P4 - ACTIVITY TO FUNCTION MAPPING

6.10 L4-P4 – Activity to Function Mapping NAFv3: NSV-5

The L4-P4 Viewpoint is concerned with:

• Addressing the linkage between functions described in P4, Resource Functions, and operational
activities specified in L4, Logical Activities.
• Addressing the Resource Functions from the P4 Viewpoint and the Service Functions from the S4
Viewpoint.
Views implementing this Viewpoint:
• Shall depict the mapping of Resource Functions (and optionally, the resources that provide them) to
operational activities or service functions.
• Shall identify the transformation of an operational need into a purposeful action performed by a
system or solution.
• Shall provide the link between the services used at the operational level and the specific Resource
Functions provided by the resources supporting the services.
CONCERNS ADDRESSED USAGE
• Requirements Definition. • Tracing functional system requirements to
• Process Mapping. user requirements.
• Tracing solution options to requirements.
• Identification of overlaps.

REPRESENTATION
• Tabular.
• Matrix.
• Diagram.
 NAFv4@ArchiMate 87

38.1 L4-P4 Objects [by NAF Layer]

# Business # Technology # Application

Function Function Function

# Technology # Equipment # Application

# Business Node
Node Node Node

# Business # Technology # Application

Service Service Service

# Technology # Equipment
# Person # Organisation # Application
Resource Resource

# Operational
Activity

# Technology # Application
# Business
Resource Resource
Resource
Function Function
Function

38.2 L4-P4 Implementation Guidance

Services, Service Functions and Resource Functions exist at 3 layers within ArchiMate. Nodes and
Resources exist at 4 layers within ArchiMate, any or all all of these layers may be present within this
viewpoint.
Resource Functions are assigned to an Active Resource at the Physical layer, which in turn realizes a
Service, this Service is also realized by the Node at the Logical layer, which has assigned the
equivalent Service Function.
Operational Activities are served by Resource Functions at the Physical layer, and by Nodes at the
Logical layer.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Resource # Equipment Resource Equipment
Function # Application Resource Function Application function
Resource Function # Application Resource Function Application function
Node # Business Node Business actor
Service # Business Service Business service
Resource # Organisation Business actor
88 NAFv4@ArchiMate

Resource # Technology Resource Node

Node # Technology Node Node
Node # Equipment Node Equipment
Service # Technology Service Technology service
Service Function # Technology Function Technology function
Resource # Person Business actor
Service Function # Application Function Application function
Function # Technology Resource Function Technology function
Resource Function # Technology Resource Function Technology function
Node # Application Node Application component
Service # Application Service Application service
Service Function # Business Function Business function
Function # Business Resource Function Business function
Resource Function # Business Resource Function Business function
Resource # Application Application component
OperationalActivity # Operational Activity Business process
 NAFv4@ArchiMate 89

39 P5 - RESOURCE STATES

P5 – Resource States NAFv3: NSV-10B

The P5 Viewpoint is concerned with Resource Types changing state in response to events and other
stimuli.
Views implementing this Viewpoint:
• Shall identify the states a Resource Type can be, the allowable changes between those states, and
the triggers that cause the state changes.
• Shall relate events to Resource Type states and describe the transition from one state to another
from a resource perspective, with a focus on how the Resource Type responds to stimuli (e.g. triggers
and events).
• May describe different responses depending upon the rule set or conditions that apply, as well as the
CONCERNS ADDRESSED USAGE
• Systems Engineering. • Definition of states, events and state
• Safety Cases. transitions (behavioural modelling).
• Identification of constraints.

REPRESENTATION
• State diagram.
 90 NAFv4@ArchiMate

39.1 P5 Objects [by NAF Layer]

# Organisation

# Post # Business
Resource State

# Person

# Technology
Resource

# Technology
Resource State
# Equipment
Resource

# Application
# Application
Resource State

39.2 P5 Implementation Guidance

Resources exist at any of 4 ArchiMate layers, and depending on their layer are represented by
Business Actor, Application Component, Technology Node and Equipment.
States exist at any of 3 ArchiMate layers, represented by Events, where relevant to the architecture it
mut be present within this viewpoint.
An Active Resource shall be associated with one or more States that correspond to the appropriate
layer for the Active Resource. Transitions between States may be depicted through the use of a
triggering relation.
Specific external triggers mentioned in the NAFv4 viewpoint description are not included here for
consistency with similar viewpoints at other NAFv4 layers.
 NAFv4@ArchiMate 91

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Resource # Organisation Business actor
State # Application Resource State Application event
ResourceStateDescription # Application Resource State Application event
State # Technology Resource State Technology event
ResourceStateDescription # Technology Resource State Technology event
State # Business Resource State Business event
ResourceStateDescription # Business Resource State Business event
Resource # Technology Resource Node
Resource # Application Application component
Resource # Post Business role
Resource # Equipment Resource Equipment
Resource # Person Business actor
 92 NAFv4@ArchiMate

40 P6 RESOURCE SEQUENCE

P6 – Resource Sequence NAFv3: NSV-10C

The P6 Viewpoint is concerned with the time-ordered examination of the interactions between
Resource Types.
Views implementing this Viewpoint:
• Shall specifies sequences in which data elements are exchanged in context of a Resource Type or
Port.
• Shall include a time-ordered representation of the data elements exchanged between participating
Resource Type or Ports.
• May represent flows of materiel, human resources or energy as interactions.
CONCERNS ADDRESSED USAGE
• Message Handling. • Analysis of resource events impacting
• Complex System Behaviours. operation.
• Security Modelling. • Behavioural analysis.
• Identification of non-functional system
requirements.

REPRESENTATION
• Topological (connected shapes).
• Sequence Diagram (preferred).
 NAFv4@ArchiMate 93

40.1 P6 Objects [by NAF Layer]

# Technology # Equipment
# Organisation # Person # Application
Resource Resource

# Resource Interaction

# Data Product # Energy # Material

40.2 P6 Implementation Guidance

Resources exist at any of 4 ArchiMate layers, and depending on their layer are represented by
Business Actor, Application Component, Technology Node and Equipment.
Active Resources are associated with Resource Interaction either as the originator or the terminator
of a specific Resource Interaction, whilst Passive Resources and Data Resources are accessed
(conveyed) during the Resource Interaction. Specific Ports have not been included in this viewpoint
as P2.
Attributes for Resource Interactions can be added for the start and end point [in time] of the
Resource Interaction in the sequence, although these will be evident as part of the triggering
relation between Resource Interactions.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Data Element # Data Product Artifact
Resource # Data Product Artifact
Energy # Energy Material
Resource # Energy Material
Resource # Organisation Business actor
Resource # Person Business actor
Resource # Application Application component
Resource # Material Material
Resource # Equipment Resource Equipment
Resource # Technology Resource Node
Resource Interaction # Resource Interaction Technology interaction
 94 NAFv4@ArchiMate

41 P7 - DATA MODEL

P7 – Data Model NAFv3: NSV-11A, B

The P7 Viewpoint is concerned with the structure of data used by the resource types in the architecture.
Views implementing this Viewpoint:
• Shall map a given information model (L7) to the logical or physical data model (P7) if both models are
used.
• Shall describe how the information represented in the L7 Information Model Viewpoint is
implemented for a given solution.
• May also simply be a text schema (e.g. in the case of SQL or ISO10303-11).
CONCERNS ADDRESSED USAGE
• System Design. • Specifying the data elements exchanged
• Data Schema Design. between systems (thus reducing the risk of
• Message / Protocol Specification. interoperability errors).
• Data Architecture. • Definition of logical or physical data structure
• Database Design. (input to system design).

REPRESENTATION
• Formal text data modelling language.
• Topological (connected shapes).
• Class diagram.
 NAFv4@ArchiMate 95

41.1 P7 Objects [by NAF Layer]

# Data Model

# Information
# Data Entity
Element

# Data Attribute

41.2 P7 Implementation Guidance

Data Entities are associated with a Data Model in this viewpoint both represented as Artefacts. The
Data Entity can be traced back to the the logical Information Element via a relaization relation. The
Data Attributes of the Data Entity are represented visually here by the use of Requirement.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Data Model # Data Model Artifact
Information Element # Information Element Data object
Data Element # Data Entity Artifact
Attribute # Data Attribute Requirement
 96 NAFv4@ArchiMate

42 P8 - RESOURCE CONSTRAINTS

P8 – Resource Constraints NAFv3: NSV-10A

The P8 Viewpoint is concerned with functional and non-functional constraints on the implementation
aspects of the architecture (i.e. the structural and behavioural elements of the Resource layer).
Views implementing this Viewpoint:
• Shall include constraints on the resource types, resource functions, data and ports.
• Shall include the rules that control, constrain or otherwise guide the implementation aspects of the
architecture.
CONCERNS ADDRESSED USAGE
• Non-Functional Requirements. • Definition of implementation logic.
• Safety Cases. • Identification of resource constraints.

REPRESENTATION
• Text (preferably specified in a computer-interpretable constraint language such as OCL).
• Tabular.
 NAFv4@ArchiMate 97

42.1 P8 Objects [by NAF Layer]

# Business # Application # Technology

Resource Resource Resource # Material # Energy # Data Product
Function Function Function

# Technology # Equipment
# Post # Organisation # Person # Application
Resource Resource

# Resource
Requirement

42.2 P8 Implementation Guidance

Resources exist at any of 4 ArchiMate layers, and depending on their layer are represented by
Business Actor, Application Component, Technology Node and Equipment
All Active Resources, Data Resources (Artefacts), Passive Resources (Material) and Resource
Functions can realize a Resource Requirement
There is no suitable ArchiMate concept to represent the 'guide the implementation of' element of
the NAF viewpoint description, Fit Criteria such as these may be modelled as an attribute of the
requirement.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Function # Technology Resource Function Technology function
Resource Function # Technology Resource Function Technology function
Resource # Post Business role
Resource # Application Application component
Function # Business Resource Function Business function
Resource Function # Business Resource Function Business function
Resource # Technology Resource Node
Resource # Material Material
Resource # Energy Material
Data # Data Product Artifact
Resource # Data Product Artifact
Function # Application Resource Function Application function
Resource Function # Application Resource Function Application function
Resource # Person Business actor
Resource # Equipment Resource Equipment
Constraint # Resource Requirement Requirement
Rule # Resource Requirement Requirement
Resource # Organisation Business actor
 98 NAFv4@ArchiMate

43 PR - CONFIGURATION MANAGEMENT

Pr – Configuration Management NAFv3: NSV-8

The Pr Viewpoint is concerned with the whole lifecycle View of a resource, describing how its
configuration changes over time.
Views implementing this Viewpoint:
• Shall include an overview of how a Resource Type structure changes over time (open to all Resource
Types).
• Shall include the structure of different versions of Resource Type (usually Capability Configurations or
Service Implementations) mapped against a timeline.
A Pr View can be used as an architecture evolution project plan or transition plan. In meta-model terms,
a Pr View is constructed from data specified in the Lr, Lines of Development, and P2, Resource Structure
Views, though there may be several P2 Views – one for each version of the configuration. Using similar
modelling elements as those used in the P2, Resource Structure Views, this View shows the structure of
the Resource Types under configuration control. Resource interactions which take place within the
Resource Type boundaries may also be shown. The changes depicted in the Pr View are derived from
the project milestones that are also shown in Lr, Lines of Development.
CONCERNS ADDRESSED USAGE
• Product Lifecycle Management. • Development of incremental acquisition
• Version Control. strategy.
• Release Scheduling. • Configuration Management.
• Planning technology insertion.

REPRESENTATION
• Timeline view.
• Herringbone style diagram.
• Augmented chart in style of a Gantt Chart.
 NAFv4@ArchiMate 99

43.1 Pr Objects [by NAF Layer]

# Enterprise
Phase

# Capability Configuration

# Technology # Equipment
# Post # Person # Organisation # Application
Resource Resource

# Energy # Material # Data Product

43.2 Pr Implementation Guidance

A Capability Configuration must be present on this viewpoint, as a Grouping. The Capability

Configuration must have attributes for the start and end dates of any readiness level appropriate for
it, these are not shown on the viewpoint. These dates can then be linked to the Enterprise Phase via
a realization relation
Visually this will be similar to a Gantt chart. The description here is for modelling purposes only.

NAFv4 Name NAFv4 ArchiMate Name ArchiMate Name

Resource # Material Material
Timeline # Enterprise Phase Plateau
Resource # Technology Resource Node
CapabilityConfiguration # Capability Configuration Grouping
Resource # Post Business role
Resource # Person Business actor
Resource # Equipment Resource Equipment
Resource # Organisation Business actor
Resource # Energy Material
Resource # Application Application component
Resource # Data Product Artifact