ISO/TR 21965:2019

TECHNICAL ISO/TR
REPORT 21965
First edition
2019-03
Information and documentation —
Records management in enterprise
architecture
Information et documentation — Gestion des documents d'activité
dans les architectures (des systemes d'information) d'entreprise
Reference number
©
ISO 2019
© ISO 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2019 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Records management viewpoint purpose and content overview . 7
4.1 Records management viewpoint purpose . 7
4.2 Records management viewpoint and the ADM. 8
5 View: Records management business context and stakeholders . 8
5.1 Records management in the business context . 8
5.2 Records management stakeholders . 9
6 View: Records management information .11
7 View: Records management motivation — Goals .12
8 View: Records management motivation — Capability .13
9 View: Records business management motivation — Architecture principles .14
9.1 General .14
9.2 Records management architecture principles .17
10 View: Records management reference application scenarios .21
11 View: Records management strategy and implementation .23
12 Records management and the Architecture Development Method .24
12.1 General .24
12.2 Areas of concern for records management within enterprise architecture .25
12.3 Records management objectives by method phase .26
Annex A (informative) Relationships to ISO records management standards .28
Annex B (informative) Alignment of records management principles to ISO records
management standard .29
Annex C (informative) Alignment with the TOGAF ADM Phase .33
Annex D (informative) Other relevant ISO standards and international references .44
Annex E (informative) Summary of ArchiMate 3.0 concepts and notation .46
Annex F (informative) Archi — ArchiMate modelling tool .47
Bibliography .48
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso
.org/iso/foreword .html.
This document was prepared by Technical Committee ISO/TC 46, Information and documentation,
Subcommittee SC 11, Archives/records management.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
iv © ISO 2019 – All rights reserved

Introduction
General
A record is information created, received and maintained as evidence and as an asset by an organization
or person, in pursuit of legal obligations or in the transaction of business. Records management is
the field of management responsible for the efficient and systematic control of records, and thus the
primary source for the definition of the main principles and requirements for the records management
capability.
Enterprise architects work with stakeholders, both leaders and subject matter experts, to develop and
maintain a holistic view of the organization's strategy, processes, information assets, and information
technology. The role of the enterprise architect is to take this knowledge and ensure that the business
and IT are in alignment. The enterprise architect links the business mission, strategy and processes of
an organization to its information and technology strategy. Enterprise architects document this using
multiple architectural models or views that show how the current and future needs of an organization
will be met in an efficient, sustainable, agile, and adaptable manner.
The concept of records as information assets is consistent with the definition in ISO 15489-1:2016
of “information created, received and maintained as evidence and as an asset by an organization or
person, in pursuit of legal obligations or in the transaction of business”. Consistent good practice in the
management of the information assets of a business is most important, regardless of the broader or
narrower interpretation of the terms “record” and “records management”, and concepts of “business
record”, “evidence”, “information asset”, “legal obligations”, and “transaction” in an organization or
business.
The purpose of this document is to provide a common reference for records managers (or information
managers in general) and enterprise architects about requirements for records processes and systems.
The goal is to establish the records manager as a key stakeholder in enterprise architecture, which
supports embedding records management:
— into the strategic goals, enabling it as an organizational capability for consideration for governance,
risk and compliance;
— into the enterprise architecture requirements, to influence systems analysis, design, planning, and
change management.
Enterprise architects are highly influential in the creation of organization-wide business requirements
and in solution architectures. Enterprise architects create and maintain enterprise architecture
representations, usually comprised of multiple models or views that show how the current and future
needs of an organization will be met in an efficient, sustainable, agile, and adaptable manner. Records
requirements, principles and models can be stated in ways that can be readily incorporated into these
enterprise architecture representations to embed records processes and systems into normal business
practice and into solutions to be designed. Incorporating recordkeeping requirements into system
analysis and design will help enterprise architects link systems to recordkeeping control tools, and
thus resolve issues such as the efficient and systematic control of the creation, receipt, maintenance,
use and disposition of records. In that sense, this document has the following objectives:
a) Explaining the core concepts and records management principles to enterprise architects;
b) Explaining the core concerns of records management as an enterprise architecture viewpoint;
c) Explaining the alignment of the records management viewpoint and enterprise architecture
methods.
The records management viewpoint expressed here makes use of the concepts of “concerns” and “system
of concerns” defined in ISO/IEC/IEEE 42010, and of the concepts of “stakeholders”, “viewpoint, “view” and
“model” as also defined coherently in that standard and in the main enterprise architecture references
of The Open Group Architecture Framework (TOGAF) and ArchiMate. With reference to ArchiMate,
the main scope of this viewpoint is the motivational aspect and the layers strategy and business, with
minor considerations for the layers of application and implementation. TOGAF is used to inform how this
records management viewpoint relates to the Architecture Development Method (ADM).
NOTE For an explanation of ArchiMate diagram conventions, see Annex A.
Motivation
Since enterprise architecture often drives decisions about investment in information systems, it is
important that records management requirements can be aligned with enterprise architecture. This
ensures that enterprise architects can understand the business value realized through managed
records.
System designers can then consider building in records management capabilities by design. This
requires the expression of records management concerns in a way that is useful for representation in
architecture descriptions.
Motivations for the development of this document include the need to improve the following situations:
— Lack of understanding in many organizations that the information created and received as part of
their business activities are in fact records and therefore should be managed not only as records but
also as enterprise assets,
— Information is of growing importance as an organisational asset on its own right. New sensor
technology, big data phenomena, open data and linked data practices, etc., require efficient control
over derived information and its uses (e.g. machine learning applications, decision aid processes,
etc.), and therefore demand adequate Records Management,
— Lack of managing records not only as records but also as enterprise assets results in records
management often being de-scoped or “deferred” during systems analysis and design, shifting
architectural debt to the end of life of system’s decommissioning (end of life of a system), This
deferment can result in uncertainty and lack of fundamental knowledge in the moment of the
decommissioning, implying high risks for the business and costly corrective efforts,
— Lack of embedding records management capability in the design of systems that create and receive
records, resulting in: unmanageable records; needed authoritative information not available to the
organization; increased risk of exposure of the organization to risks (such as compliance risks) and
a loss of efficiency (such as for discovery tasks),
— Cost of re-engineering an enterprise solution designs due to compliance risks.
Understanding records management concerns within an enterprise architecture context can minimize
some of the following typical challenges:
— Reliance on manual interventions in the management of records, described:
— By Enterprise Architects as “create, describe, store, maintain and dispose of records”,
— By Records Managers as “creation, capture and management of records”.
— Records not created within, or persistently linked to, the business context (see Figure 1),
— Exposure to risks and compliance issues due to:
— Systems not designed to preserve the integrity of records, for example, not preventing
unauthorized changes to content and metadata, or with inadequate activity monitoring,
— Systems not able to destroy records when those records are due for destruction,
— Systems not designed to prevent the destruction of records that are scheduled for retention,
— Systems not recording the disposition of records,
vi © ISO 2019 – All rights reserved

— Systems with limitations for decommissioning properly, because it isn’t possible to apply
disposition rules to poorly described content or because the system lacks disposition capabilities,
— Migrations that damage the integrity of records (content, context, rendering), are compromised
through poorly designed migration processes,
— Systems unable to appropriately discover or view or retrieve records,
— Systems unable to prevent inappropriate disclosure of records, nor to publish appropriate as
open data due to inadequate metadata,
— Inability to transfer control of archival records to archival authorities.
— Overhead cost of maintaining unmanaged records indefinitely,
— Loss of reputation and legal risks associated with lack of evidence or lack of integrity of evidence.
Structure of this document
This document is organized into four main groupings:
— Clauses 1 to 3 provide the context overview, including Introduction, Scope, Normative references,
and Terms and definitions.
— Clauses 4 to 11 set out the Records Management Viewpoint in the scenarios of “Business”, “Motivation”,
“Information”, “Strategy”, “Implementation” and “Reference Application”.
— Clause 12 — Records Management and the Architecture Development Method — provides guidelines
for the consideration of Records Management concerns during an Enterprise Architecture process,
[1]
considering the ADM, as proposed by TOGAF 9 .
— Annexes supporting Clauses 4 to 12.
TECHNICAL REPORT ISO/TR 21965:2019(E)
Information and documentation — Records management
in enterprise architecture
1 Scope
The document creates a common language that embeds records management concerns and
requirements into enterprise architecture with the twin goals of building consensus
— among records managers, enterprise architects and solution architects, and
— across the domains of records management, enterprise architecture and solution architecture.
NOTE This common understanding of Records Management enables Enterprise Architects to understand the
motivations, concerns and goals of Records Managers, recognize them as influential key business stakeholders
during organizational transformation, and use this understanding to influence systems planning and design. As a
result, Records Management becomes an organizational capability at governance, strategic and operational levels.
This document provides a records management viewpoint, with architecture principles and
corresponding architectural views of records. It explains records management for enterprise
architects and other related professionals, so that they can achieve the competency needed to support
collaborative initiatives.
This document provides support to enterprise architects in areas including:
— understanding and identifying records management principles, goals and requirements significant
for the architectural representation,
— facilitating consultations with records managers during the project lifecycle,
— identifying opportunities to reuse existing records management analyses and tools.
This document provides scenarios and models for solution architects and those who have responsibility
for infrastructure overview.
This document also provides a common language to records managers for collaboration with enterprise
architects to position records management requirements in the architecture development process.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/

3.1 General
3.1.1
access
right, opportunity, means of finding, using or retrieving information
[SOURCE: ISO 15489-1:2016, 3.1]
3.1.2
activity
major task performed by a business entity as part of a function
[SOURCE: ISO 15489-1:2016, 3.2]
3.1.3
appraisal
evaluation of business activities to determine which records need to be created and captured, and how,
and how long, the records need to be kept
Note 1 to entry: In some records and archives management traditions, appraisal is solely used as an instrument
to identify retention requirements or to create a disposition authority. The concept of appraisal as defined here is
meant to be used in a broader way.
[SOURCE: ISO TR 21946: 2018, Introduction]
3.1.4
architecture
fundamental concepts or properties of a system in its environment embodied in its elements,
relationships, and in the principles of its design and evolution
[SOURCE: ISO/IEC/IEEE 42010:2011, 3.2]
3.1.5
asset
anything that has value to the organization
Note 1 to entry: There can be many types of assets, including:
a) information (such as documents and databases);
b) software, such as a computer program;
c) physical, such as a computer;
d) services (meaning capabilities to deliver something);
e) people, and their qualifications, skills, and experience; and
f) intangibles, such as reputation and image.
[SOURCE: ISO/IEC 27000:2009, 2.3]
3.1.6
authoritative record
records, regardless of form or structure, are authoritative evidence of business when they possess the
characteristics of authenticity, reliability, integrity and usability
[SOURCE: ISO 15489-1:2016, 5.2.2.]
2 © ISO 2019 – All rights reserved

3.1.7
classification
systematic identification and/or arrangement of business activities and/or records into categories
according to logically structured conventions, methods, and procedural rules
[SOURCE: ISO 15489-1:2016, 3.5]
3.1.8
system of concern
interest in a system relevant to one or more of its stakeholders (3.1.22)
Note 1 to entry: A concern pertains to any influence on a system in its environment, including developmental,
technological, business, operational, organizational, political, economic, legal, regulatory, ecological and social
influences.
[SOURCE: ISO 42010:2011, 3.7]
3.1.9
context of the organization
combination of internal and external issues that can have an effect on an organization’s approach to
developing and achieving its objectives
Note 1 to entry: The organization’s objectives can be related to its products and services, investments and
behaviour towards its interested parties.
Note 2 to entry: The concept of context of the organization is equally applicable to not-for-profit or public service
organizations as it is to those seeking profits.
Note 3 to entry: In English, this concept is often referred to by other terms such as “business environment”,
“organizational environment” or “ecosystem of an organization”.
Note 4 to entry: Understanding the infrastructure can help to define the context of the organization.
Note 5 to entry: An encapsulation of data that is recognized by a business domain expert as representing a
conceptual thing relevant for the domain model of that business (instances of information entities can become
information assets).
[SOURCE: ISO 9000:2015, 3.2.2, modified — Notes 1 to 5 to entry have been added.]
3.1.10
disposition
range of processes associated with implementing records retention, destruction or transfer
decisions, which are documented in disposition authorities or other instruments
[SOURCE: ISO 15489-1:2016, 3.8]
3.1.11
evidence
documentation of a transaction
Note 1 to entry: Proof of a business transaction which can be shown to have been created in the normal course of
business activity and which is inviolate and complete. Not limited to the legal sense of the term.
[SOURCE: ISO 15489-1:2016, 3.10, modified]
3.1.12
function
group of activities that fulfils the major responsibilities for achieving the strategic goals of a
business entity
[SOURCE: ISO 15489-1:2016, 3.11]
3.1.13
management system
set of interrelated or interacting elements of an organization to establish policies and objectives, and
processes to achieve those objectives
Note 1 to entry: A management system can address a single discipline or several disciplines, e.g. quality
management, financial management or environmental management.
Note 2 to entry: The management system elements establish the organization’s structure, roles and
responsibilities, planning, operation, policies, practices, rules, beliefs, objectives and processes to achieve those
objectives.
Note 3 to entry: The scope of a management system can include the whole of the organization, specific and
identified functions of the organization, specific and identified sections of the organization, or one or more
functions across a group of organizations.
Note 4 to entry: This constitutes one of the common terms and core definitions for ISO management system
standards given in Annex SL of the Consolidated ISO Supplement to the ISO/IEC Directives, Part 1. The original
definition has been modified by modifying Notes 1 to 3 to entry.
[SOURCE: ISO 9000:2015, 3.5.3]
3.1.14
metadata for records
structured or semi-structured information, which enables the creation, management, and use of
records through time and within and across domains
[SOURCE: ISO 15489-1:2016, 3.12]
3.1.15
metadata schema
logical plan showing the relationships between metadata elements, normally through establishing
rules for the use and management of metadata specifically about the semantics, the syntax and the
optionality (obligation level) of values
[SOURCE: ISO 23081-1:2017, 3.10]
3.1.16
migration
process of moving records from one Records Management service to another service
maintaining all the characteristics of these records
Note 1 to entry: See also definitions of this concept in ISO 30300:2011, 3.3.8 and ISO 15489-1:2016, 3.13.
3.1.17
model kind
conventions for a type of modelling
Note 1 to entry: Examples of model kinds include data flow diagrams, class diagrams, Petri nets, balance sheets,
organization charts and state transition models.
[SOURCE: ISO 42010:2011, 3.9]
3.1.18
record(s)
information created, received and maintained as evidence and as an asset (3.1.5) by an organization or
person, in pursuit of legal obligations or in the transaction of business
Note 1 to entry: The viewpoint defined in this document is intended to be useful in any enterprise architecture
scenario, and intended to prevent conflicting meanings in multiple viewpoints. The term used in the ArchiMate
modelling of this viewpoint is “business record”. In this document the term “business record” has the same
definition as the established definition for “record” in the records management domain.
4 © ISO 2019 – All rights reserved

[SOURCE: ISO 15489-1:2016, 3.14]
3.1.19
records management
field of management responsible for the efficient and systematic control of the creation, receipt,
maintenance, use and disposition (3.1.10) of records, including processes for capturing and maintaining
evidence of and information about business activities and transactions in the form of records
[SOURCE: ISO 15489-1:2016, 3.15]
3.1.20
records management capability
capability of realizing the records management (3.1.19) goals
3.1.21
records system
information system which captures, manages and provides access (3.1.1) to records (3.1.18) through time
Note 1 to entry: In the context of records management, “system” means a business system that is responsible for
automating business activities and transactions.
[SOURCE: ISO 15489-1:2016, 3.16, modified —In the definition, the word “over” has been replaced by
“through” and Note 1 to entry has been replaced.]
3.1.22
stakeholder
individual, team, organization, or classes thereof, having an interest in a system
Note 1 to entry: Different stakeholders with different roles will have different concerns
[SOURCE: ISO 42010:2011 3.10]
3.1.23
transaction
smallest unit of a work process consisting of an exchange between two or more participants or systems
[SOURCE: ISO 15489-1:2016, 3.18]
3.1.24
work process
one or more sequences of activities required to produce an outcome that complies with governing rules
Note 1 to entry: The definition above corrects here the definition “one or more sequences of actions required to
produce an outcome that complies with governing rules”.
[SOURCE: ISO 15489-1:2015, 3.19]
3.2 Terms relating to TOGAF
NOTE TOGAF 9.2 terminology is available at http: //pubs .opengroup .org/architecture/togaf9
-doc/arch/chap03 .htm.
3.2.1
actor
person, organization, or system that has one or more roles that initiates or interacts with activities
EXAMPLE A sales representative who travels to visit customers.
Note 1 to entry: Actors may be internal or external to an organization. In the automotive industry, an original
equipment manufacturer would be considered an actor by an automotive dealership that interacts with its supply
chain activities.
[SOURCE: TOGAF 9.2, 3.2, modified]
3.2.2
architecture principles
qualitative statement of intent that is intended to be met by the architecture
Note 1 to entry: Architecture principles are a set of principles that relate to architecture work. They reflect a
level of consensus across the enterprise and embody the spirit and thinking of existing enterprise principles.
Architecture principles govern the architecture process, affecting the development, maintenance, and use of the
enterprise architecture.
[SOURCE: TOGAF 9.1, 3.16]
3.2.3
architecture view
representation of a related set of concerns.
Note 1 to entry: The term view is used as a synonym for architecture view.
[SOURCE: TOGAF 9.2, 3.17]
3.2.4
architecture viewpoint
specification of the conventions for a particular kind of architecture view (3.2.3)
Note 1 to entry: An architecture viewpoint can also be seen as the definition or schema for that kind of
architecture view. It establishes the conventions for constructing, interpreting, and using an architecture view
to address a specific concern (or set of concerns) about a system-of-interest.
Note 2 to entry: The term viewpoint is used as a synonym for architecture viewpoint.
[SOURCE: TOGAF 9.2, 3.18]
3.2.5
capability
ability that an organization, person, or system possesses
EXAMPLE Marketing, customer contact, or outbound telemarketing.
[SOURCE: TOGAF 9.2, 3.30]
3.2.6
data architecture
description of the structure and interaction of the enterprise's major types and sources of data, logical
data assets, physical data assets, and data management resources
Note 1 to entry: Logical data entities can be tied to applications, repositories, and services and may be structured
according to implementation considerations.
Note 2 to entry: The concept of “data” is intentionally not defined here, as it is part of the data architecture
definition for each application scenario. It is according to the specific requirements of that scenario.
[SOURCE: TOGAF 9.2, 3.36]
3.2.7
metamodel
model that describes how and with what the architecture will be described in a structured way
[SOURCE: TOGAF 9.2, 3.50]
6 © ISO 2019 – All rights reserved

3.2.8
role
usual or expected function of an actor (3.2.1), or the part somebody or something plays in an action
or event
Note 1 to entry: It is also defined as a part an individual plays in an organization and the contribution they make
through the application of their skills, knowledge, experience, and abilities.
Note 2 to entry: An Actor may have several roles.
[SOURCE: TOGAF 9.2, 3.31]
3.2.9
solution architecture
description of a discrete and focused business operation or activity (3.1.2) and how information service
(IS)/information technology (IT) supports that operation
Note 1 to entry: A solution architecture typically applies to a single project or project release, assisting in the
translation of requirements into a solution vision, high-level business and/or IT system specifications, and a
portfolio of implementation tasks.
[SOURCE: TOGAF 9.2, 3.69]
4 Records management viewpoint purpose and content overview
4.1 Records management viewpoint purpose
The main scope of this viewpoint is the motivational aspect with the layers of strategy and MODE
business, but with considerations for the layers of application and implementation.
Table 1 summarizes this viewpoint, which is defined below with the following model artefacts:
— Table 2: Core records management stakeholder map matrix;
— Figure 3: Records management information view (ArchiMate diagram);
— Figure 4: Records management information view (UML class diagram);
— Figure 5: Records management business motivation view — Goals (ArchiMate diagram);
— Figure 6: Records management business motivation view — Capability (ArchiMate diagram);
— Figure 8: Records management motivation view — Architecture principles (ArchiMate diagram);
— Figure 9: Records management reference application scenarios (ArchiMate diagrams);
— Figure 10: Records management strategy and implementation view (ArchiMate diagram).
Table 1 — Records management viewpoint description
Records management viewpoint
Stakeholders — Enterprise architect
— Records manager (as specific motivational Domain architect)
— Process architect (to identify transaction activities)
— Domain architect (to identify business records and records metadata)
— Business analyst (to identify Compliance requirements)
a
— C-Level manager
Concerns — Architecture strategy and tactics
— Motivation (ArchiMate defines motivation elements as: Value, Meaning, Driver, Assessment,
Goal, Outcome, Principle and Requirement. This viewpoint focuses on the elements
Principle and Requirement, as identified in the Records Management body of knowledge)
— Responsibilities (collaborations with Records Managers)
Purpose — Designing
— Deciding
— Informing
Scope — Motivational Aspect
— Multiple Layer (Strategy, Business, Application and Implementation)
a
High-ranking executive titles within an organization, who are typically considered the most powerful and influential
positions of an organization, setting the strategy and making high-stake decisions. Common examples of these positions
are: Chief Executive Officer (CEO), Chief Financial Officer (CFO), Chief Information Officer (CIO), Chief Security Officer
(CSO), Chief Information Security Officer (CISO), Chief human resources officer (CHRO), Chief compliance officer (CCO), etc.
Because they are not relevant for the definition of this viewpoint, the eventual relationship between the senior Managers
and other classes of stakeholders of “Program Manager” and “Records Manager” are here intentionally ignored (in a real
scenario, they might depend of each specific organizational structure).
4.2 Records management viewpoint and the ADM
Records management does not need to be treated as a separate architecture domain. Its concerns can
all be expressed in requirements relating to the main architecture domains and phases of the ADM
proposed in TOGAF.
Clause 12 explains how the records management viewpoint can be aligned with the ADM. Annex C
provides more details for that purpose.
5 View: Records management business context and stakeholders
5.1 Records management in the business context
ISO 23081-1:2017, 9.1 and Figure 1 describe that records are scoped within their business context.
Organizations are socio-technical systems, in the sense that they consist of workplaces of people
interacting with technology. Business contexts are organizations that are commonly understood as
processes, information, technology and people that should interact with each other and with their
environment in support of a common business objective.
The context where business is done is defined by mandates, which can be either external, such as laws,
regulations, standards, etc., or internal, such as policies, responsibilities, delegations, etc. In the course
of doing business, records are the documented evidence of how the business is done, thus they account
for the execution of the mandates. In this way, records management is integrated into business.
8 © ISO 2019 – All rights reserved

1)
Figure 1 — Records management and the business context
Figure 1 shows relationships between business, agent (equivalent to a TOGAF actor), and record entities
at any layer of aggregation and through time. Business to business, business records management to
business records management, agent to agent, and record to record relationships can also be depicted in
and through time. Any single agent, business context, business records management context, or records
entity might have relationships with like or unlike entities that extend through layers of aggregation in
2)
ways that establish a rich envelope of contextual metadata .
This means business systems (including cloud-hosted business systems) might be expected to manage
records, implying they should consider the inclusion of records management capabilities in those
systems. The authoritativeness of records is supported when their management systems deliver the
capabilities of being reliable, secure, compliant, comprehensive and systematically managed. Systems
managing records, regardless of their degree of automation, enable the execution of processes
for creating, capturing and managing records. They depend on defined policies, responsibilities,
monitoring, evaluation and training to meet identified records management requirements.
Where business processes are collaborative between organizations, business contexts might also
require interoperability between local and external business systems. Any interoperability requirement
would impose specific requirements that systems managing records would also take in consideration.
5.2 Records management stakeholders
It is important to first identify the stakeholders’ power, influence, and interest around the
records management capability, and then to focus the Enterprise Architecture engagement on the
corresponding key individuals. These classes of stakeholders can be mapped onto a power/interest
1) Source: ISO 23081-1:2017, Figure 1.
2) Note Mandates are referred to (but not defined) in ISO 15489-1:2016, S 8.2 as “laws and other requirements
governing the conduct of business and record creation or management”.
matrix, as illustrated by Figure 2, which also indicates which strategy to adopt for engaging with these
stakeholders.
Table 2 shows reference classes of stakeholders that can be considered for the definition of the records
management viewpoint. The Rating (B, C or D) is taken from Figure 2. Table 2 is not prescriptive, but
only a reference for the description of generic roles (in real scenarios, real roles would be considered
case by case, and also considering the level of application in that case of other references, as for example
Reference [4]).
Figure 2 — Stakeholder map matrix concept
Table 2 — Core records management stakeholder map matrix
Stakeholder Involvement Rating Strategy Relevant artefacts
C-level Manager Any senior high management-level position in C Keep — Business footprint
the organization. This group is interested in satisfied
— Goals, Objectives
the high-level drivers, goals and objectives of
and Service model
the organization, and in how to translate these
into an effective Records Management process to
— Organizational
advance the business in a compliant conscience
chart
and risk awareness.
Program This specific group is interested in prioritising, C Keep — Roadmaps
Manager funding, and aligning change activity. An under- satisfied
— Business footprint
standing of Records Management and technical
dependencies adds a further dimension of richness
— Application
to portfolio management and decision-making.
communication
— Functional
decomposition
Records Key stakeholder who needs to be involved in D Key player All
Manager defining the Records Management capability.
Business Key stakeholder who are involved in the execu- D Key player — Roadmaps
worker tion of the work processes, and therefore needs
— Business footprint
(end user) to be involved in defining the efficiency of the
Records Management capability.
— Functional
decomposition
Customer Stakeholder with indirect concerns on the B Keep — External
(including Records Management changes, for consideration informed functionality
business if, for example, the business has an identified
partners) requirement to provide external interfaces for
customers to store or retrieve records as business
objects. This class of stakeholders also comprises
business partners.
10 © ISO 2019 – All rights reserved

6 View: Records management information
ISO 15489-1 describes records controls and records processes in a way that allows for flexibility in
implementation choices. However, and in alignment with Figure 1, we can produce the generic records
management metamodel information viewpoint as illustrated in the diagrams in Figure 3 and Figure 4
(respectively as an ArchiMate diagram and as a UML class diagram expressing a conceptual domain
model, a language that is also expected to be familiar to Enterprise Architects).
Business work process
Business activity
Business transaction
is associated is associated
Business record Business activity
Data
is associated classication
specializes
specializes has
realizes
Business
Business object Data object
process
Record metadata Record
is part of
Figure 3 — Records management information view (ArchiMate diagram)
3)
Figure 4 — Records management information view (UML class diagram)
This view can be described as follows.
— In an organization, an outcome is produced by a “Business work process”, comprising of the set of
activities required to produce the intended outcome.
3) The Unified Modeling Language (UML) is an engineering language that is intended to provide a standard way to
represent the design of a logical system.
— Where an activity comprises an exchange between two or more participants, it means a transaction
has occurred. The main purpose of records management is the efficient and systematic management
of information that is evidence of business transactions. This implies that information generated
about a “Business transaction” is created and managed as a record and according to established
conventions, methods, and procedural rules.
— A “Record” is therefore a fact, which, as a business concept, is like any other type of “Data” modelled
in the data architecture as any other asset created and maintained by the organization (in this case,
representing evidence of a “Business transaction” according to the “Business activity classification”
of the relevant activities).
— As a specialization of “Data”, a “Record” is therefore an asset of an organization, and like any
other Data, a “Record” can be made of other “Data Entities” (e.g. structured or unstructured data,
contracts, letters, invoices, images, voice recordings, etc.), and consequently, of other “Records”.
— Finally, a “Record” also can have in its composition specialized “Data Entities” of the kind “Record
metadata” (metadata for records is structured or semi-structured information intended to support
the lifecycle of records; metadata schema models the relationships between metadata elements).
In conclusion, being a business asset, a “Record” is properly managed, which requires “Record
metadata”, a type of “Data” that becomes part of “Record”.
7 View:
...

RAPPORT ISO/TR
TECHNIQUE 21965
Première édition
2019-03
Information et documentation —
Gestion des documents d'activité
dans les architectures (des systémes
d'information) d'entreprise
Information and documentation — Records management in
enterprise architecture
Numéro de référence
©
ISO 2019
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2019
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
Fax: +41 22 749 09 47
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii © ISO 2019 – Tous droits réservés

Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Objectif du point de vue de la gestion des documents d'activité et vue d'ensemble
du contenu. 7
4.1 Objectif du point de vue de la gestion des documents d'activité . 7
4.2 Point de vue de la gestion des documents d'activité et méthode ADM . 8
5 Vue: Contexte opérationnel et parties prenantes de la gestion des documents d'activité .9
5.1 Gestion des documents d'activité dans le contexte opérationnel . 9
5.2 Parties prenantes de la gestion des documents d'activité.10
6 Vue: Informations relatives à la gestion de documents d'activité .11
7 Vue: Motivation pour la gestion des documents d'activité — Objectifs .13
8 Vue: Motivation pour la gestion des documents d'activité — Capacité .14
9 Vue: Motivation pour la gestion des documents d'activité — Principes d'architecture .16
9.1 Généralités .16
9.2 Principes d'architecture de gestion des documents d'activité .19
10 Vue: Scénarios d'application de référence pour la gestion des documents d'activité .25
11 Vue: Stratégie de gestion des documents d'activité et mise en œuvre .27
12 Gestion des documents d'activité et méthode de développement de l'architecture .29
12.1 Généralités .29
12.2 Domaines de sujets d'intérêt pour la gestion des documents d'activité au sein
de l'architecture d'entreprise .30
12.3 Objectifs de gestion des documents d'activité par phase de la méthode .31
Annexe A (informative) Liens avec les normes ISO de gestion des documents d'activité .33
Annexe B (informative) Alignement des principes de gestion des documents d'activité sur
les normes ISO de gestion des documents d'activité .34
Annexe C (informative) Harmonisation avec la phase ADM TOGAF .38
Annexe D (informative) Autres normes ISO et références internationales pertinentes .51
Annexe E (informative) Résumé des concepts et de la notation d'ArchiMate 3.0.53
Annexe F (informative) Archi — Outil de modélisation ArchiMate .54
Bibliographie .55
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes
nationaux de normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est
en général confiée aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l'ISO participent également aux travaux.
L'ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier, de prendre note des différents
critères d'approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www
.iso .org/directives).
L'attention est attirée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l'élaboration du document sont indiqués dans l'Introduction et/ou dans la liste des déclarations de
brevets reçues par l'ISO (voir www .iso .org/brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion
de l'ISO aux principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles
techniques au commerce (OTC), voir www .iso .org/avant -propos.
Le présent document a été élaboré par le comité technique ISO/TC 46, Information et documentation,
sous-comité SC 11, Archives/gestion des documents d'activité.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l’adresse www .iso .org/fr/members .html.
iv © ISO 2019 – Tous droits réservés

Introduction
Généralités
Un document d'activité regroupe des informations créées, reçues et préservées comme preuve et
actif par une personne physique ou morale dans l'exercice de ses obligations légales ou la conduite
des opérations liées à son activité. La gestion des documents d'activité est le domaine de la gestion
en charge d'un contrôle efficace et systématique des documents d'activité, et donc la principale source
pour définir les principes fondamentaux et les exigences essentielles relatifs à la capacité de gestion des
documents d'activité.
Les architectes (des systèmes d'information) d'entreprise travaillent avec les parties prenantes,
tant les dirigeants que les experts en la matière, pour élaborer et maintenir une vision globale de la
stratégie, des processus, des actifs informationnels et des technologies de l'information. Le rôle de
l'architecte d'entreprise est de prendre en compte ces connaissances et de s'assurer que l'organisme et
l'informatique sont cohérents. L'architecte d'entreprise établit un lien entre la mission, la stratégie et
les processus opérationnels d'un organisme et sa stratégie en matière d'information et de technologie.
Les architectes d'entreprise illustrent cela à l'aide de multiples modèles architecturaux ou vues
architecturales qui montrent comment les besoins actuels et futurs d'un organisme seront satisfaits
d'une manière efficace, durable, agile et adaptable.
Le concept de «documents d'activité» en tant qu'actifs informationnels est conforme à la définition
donnée dans l'ISO 15489-1:2016: «informations créées, reçues et préservées comme preuve et actif par
une personne physique ou morale dans l'exercice de ses obligations légales ou la conduite des opérations
liées à son activité». Dans la gestion des actifs informationnels d'un organisme, le plus important est
la cohérence des bonnes pratiques, quelle que soit l'interprétation plus ou moins large des termes
«document d'activité» et «gestion des documents d'activité», ainsi que des concepts de «documents
d'activité opérationnels», «preuve», «actif informationnel», «obligations légales»et de «transaction» au
sein de l'organisme ou de l'organisation.
Le présent document a pour but de proposer une référence commune aux responsables de la gestion de
documents d'activité (ou aux responsables de l'information en général) et aux architectes d'entreprise
concernant les exigences relatives aux processus et aux systèmes documentaires. L'objectif est que
le responsable de la gestion des documents d'activité devienne un acteur clé de l'architecture (des
systèmes d'information) d'entreprise, qui accompagne l'intégration de la gestion des documents
d'activité:
— dans les objectifs stratégiques, ce qui en fait une capacité organisationnelle à prendre en compte en
matière de gouvernance, de risque et de conformité;
— dans les exigences de l'architecture d'entreprise, afin d'influencer les systèmes d'analyse, la
conception, la planification et la gestion des changements.
Les architectes d'entreprise ont une grande influence sur la création d'exigences opérationnelles
à l'échelle de l'organisme et sur les architectures de solutions. Les architectes d'entreprise créent et
maintiennent des représentations d'architecture d'entreprise, généralement composées de plusieurs
modèles ou vues qui montrent comment les besoins actuels et futurs d'un organisme seront satisfaits
d'une manière efficace, durable, agile et adaptable. Les exigences, les principes et les modèles en
matière de documents d'activité peuvent être énoncés de manière à pouvoir être facilement intégrés
à ces représentations de l'architecture d'entreprise afin d'intégrer les processus et les systèmes
documentaires aux pratiques opérationnelles normales et aux solutions à concevoir. L'intégration des
exigences en matière de tenue des documents d'activité dans l'analyse et la conception des systèmes
aidera les architectes d'entreprise à relier les systèmes aux outils de contrôle de la tenue des documents
d'activité et à résoudre ainsi des problèmes tels que le contrôle efficace et systématique de la création,
de la réception, de la maintenance, de l'utilisation et du sort final des documents d'activité. En ce sens,
le présent document vise les objectifs suivants:
a) expliquer les concepts de base et les principes de la gestion des documents d'activité aux architectes
d'entreprise;
b) expliquer les principaux sujets d'intérêt de la gestion des documents d'activité du point de vue de
l'architecture d'entreprise;
c) expliquer le lien entre le point de vue de la gestion des documents d'activité et les méthodes
d'architecture d'entreprise.
Le point de vue de la gestion des documents d'activité exprimé dans le présent document se base sur
les concepts de «sujets d'intérêt» et «systèmes d'intérêt» définis dans l'ISO/IEC/IEEE 42010, ainsi
que sur les concepts de «parties prenantes», «points de vue», «vue» et «modèle» également définis de
manière cohérente dans cette norme et dans les principales références en architecture d'entreprise que
sont TOGAF (The Open Group Architecture Framework) et ArchiMate. En ce qui concerne ArchiMate, le
principal domaine d'application de ce point de vue est l'aspect de motivation et les couches stratégie et
métier, avec des considérations mineures pour les couches application et implémentation. Le TOGAF est
utilisé pour déterminer la façon dont ce point de vue de la gestion des documents d'activité est lié à la
méthode ADM (Architecture Development Method).
NOTE Pour une explication des conventions du diagramme ArchiMate, voir l'Annexe E.
Motivation
Étant donné que l'architecture d'entreprise oriente souvent les décisions d'investissement dans
les systèmes d'information, il est important que les exigences en matière de gestion des documents
d'activité puissent être alignées avec l'architecture d'entreprise. Ainsi, les architectes d'entreprise
peuvent comprendre la plus-value opérationnelle réalisée grâce à la gestion des documents d'activité.
Les concepteurs de systèmes peuvent alors envisager d'intégrer des capacités de gestion des documents
d'activité dès la conception. Pour ce faire, il faut exprimer les sujets d'intérêt relatifs à la gestion
des documents d'activité d'une manière qui soit utile pour la représentation dans les descriptions
d'architecture.
Parmi les raisons qui ont motivé l'élaboration du présent document figure la nécessité d'améliorer les
situations suivantes:
— beaucoup d'organismes ne comprennent pas que l'information créée et reçue dans le cadre de leurs
activités opérationnelles constitue en fait des documents d'activité et devrait donc être gérée non
seulement comme des documents d'activité, mais aussi comme des actifs de l'entreprise;
— l'information est de plus en plus importante en tant qu'actif organisationnel à part entière. Les
nouvelles technologies de détection, les phénomènes de big data, et les pratiques relatives aux
données ouvertes et liées, etc., exigent un contrôle efficace de l'information dérivée et de ses
utilisations (par exemple applications d'apprentissage machine, processus d'aide à la décision, etc.)
et nécessitent donc une gestion adéquate des documents d'activité;
— l'absence de gestion des documents d'activité non seulement en tant que documents d'activité,
mais aussi en tant qu'actifs de l'entreprise, fait que la gestion des documents d'activité est souvent
supprimée ou «différée» lors de l'analyse et de la conception des systèmes, ce qui entraîne un
report de la dette architecturale à la fin de la vie utile du système (mise hors service), ce qui peut se
traduire par des incertitudes et un manque de connaissances fondamentales au moment de la mise
hors service, entraînant des risques élevés pour les activités et de coûteux efforts correctifs;
— un manque d'intégration de la capacité de gestion des documents d'activité dans la conception
des systèmes de création et de réception des documents d'activité, ce qui entraîne: des documents
d'activité ingérables; des informations officielles nécessaires auxquelles l'organisme n'a pas accès;
un risque accru d'exposition de l'organisme à des risques (comme les risques de conformité) et une
perte d'efficacité (comme les tâches de découverte);
— le coût de la réingénierie de la conception d'une solution d'entreprise en raison des risques liés à la
conformité.
vi © ISO 2019 – Tous droits réservés

Comprendre les sujets d'intérêt relatifs à la gestion des documents d'activité dans le contexte d'une
architecture d'entreprise peut réduire au minimum certains des défis types suivants:
— le recours à des interventions manuelles dans la gestion des documents d'activité, décrit:
— par les architectes d'entreprise comme consistant à «créer, décrire, entreposer, tenir à jour et
décider du sort final des documents d'activité»;
— par les responsables de la gestion de documents d'activité comme consistant à «créer, capturer
et gérer les documents d'activité»;
— les documents d'activité qui ne sont pas créés dans le contexte opérationnel ou qui n'y sont pas liés
en permanence (voir Figure 1);
— l'exposition aux risques et aux problèmes de conformité dus à:
— des systèmes qui ne sont pas conçus pour préserver l'intégrité des documents d'activité, par
exemple, qui n'empêchent pas les modifications non autorisées du contenu et des métadonnées,
ou dont la surveillance des activités est insuffisante;
— des systèmes qui ne sont pas en mesure de détruire les documents d'activité lorsqu'ils
doivent l'être;
— des systèmes qui ne sont pas conçus pour empêcher la destruction des documents d'activité
dont la conservation est prévue;
— des systèmes qui n'enregistrent pas le sort final des documents d'activité;
— des systèmes ayant des capacités limitées pour effectuer une mise hors service correctement,
parce qu'il n'est pas possible d'appliquer des règles de sort final à des contenus mal décrits ou
parce que le système n'est pas doté de capacités de gestion du sort final;
— des migrations qui portent atteinte à l'intégrité des documents d'activité (contenu, contexte,
rendu), qui sont compromises par des processus de migration mal conçus;
— des systèmes qui ne sont pas en mesure de découvrir, de visualiser ou de récupérer les documents
d'activité de façon appropriée;
— des systèmes qui sont incapables d'empêcher la divulgation inappropriée de documents
d'activité, ni de publier des données appropriées sous forme de données ouvertes en raison de
métadonnées inadéquates;
— l'incapacité de transférer le contrôle des documents d'activité à conserver aux autorités
d'archives;
— les frais généraux liés à la tenue de dossiers non gérés pour une période indéterminée;
— la perte de réputation et les risques juridiques associés au manque de preuves ou à l'absence
d'intégrité des preuves.
Structure du présent document
Le présent document est organisé selon quatre grandes sections:
— les Articles 1 à 3 donnent un aperçu du contexte, avec notamment les parties Introduction, Domaine
d'application, Références normatives et Termes et définitions;
— les Articles 4 à 11 exposent le point de vue de la gestion des documents d'activité dans les scénarios
«Métier», «Motivation», «Information», «Stratégie», «Implémentation» et «Application de référence»;
— l'Article 12 — Gestion des documents d'activité et méthode ADM (Architecture Development Method) —
fournit des lignes directrices pour la prise en compte des sujets d'intérêt relatifs à la gestion des
documents d'activité au cours d'un processus d'architecture d'entreprise, compte tenu de l'ADM,
[10]
comme le propose le TOGAF 9 ;
— les annexes sur lesquelles s'appuient les Articles 4 à 12.
viii © ISO 2019 – Tous droits réservés

RAPPORT TECHNIQUE ISO/TR 21965:2019(F)
Information et documentation — Gestion des documents
d'activité dans les architectures (des systémes
d'information) d'entreprise
1 Domaine d'application
Ce document crée un langage commun qui intègre les sujets d'intérêt et les exigences en matière de
gestion des documents d'activité dans l'architecture (des systèmes d'information) d'entreprise avec le
double objectif de faire naître un consensus:
— entre les responsables de la gestion de documents d'activité, les architectes (des systèmes
d'information) d'entreprise et les architectes de solutions; et
— à travers les domaines de la gestion des documents d'activité, de l'architecture d'entreprise et de
l'architecture de solutions.
NOTE Cette compréhension commune de la gestion des documents d'activité permet aux architectes
d'entreprise de comprendre les motivations, les sujets d'intérêt et les objectifs des responsables de la gestion
de documents d'activité, de les reconnaître comme des intervenants opérationnels clés influents pendant
la transformation organisationnelle et d'utiliser cette compréhension pour influencer la planification et la
conception des systèmes. Ainsi la gestion des documents d'activité devient une capacité organisationnelle au
niveau de la gouvernance, de la stratégie et des opérations.
Le présent document présente un point de vue sur la gestion des documents d'activité, avec les principes
d'architecture et les vues architecturales correspondantes des documents d'activité. Il explique la
gestion des documents d'activité pour les architectes d'entreprise et autres professionnels connexes,
afin qu'ils puissent acquérir les compétences nécessaires pour soutenir les initiatives de collaboration.
Le présent document fournit un soutien aux architectes d'entreprise dans les domaines suivants:
— comprendre et déterminer les principes, les objectifs et les exigences en matière de gestion des
documents d'activité qui sont importants pour la représentation architecturale;
— faciliter les consultations avec les responsables de la gestion de documents d'activité pendant le
cycle de vie du projet;
— déterminer les possibilités de réutiliser les analyses et les outils de gestion des documents d'activité
existants.
Le présent document fournit des scénarios et des modèles destinés aux architectes de solutions et à
ceux qui ont la responsabilité de la vue d'ensemble de l'infrastructure.
Le présent document fournit également un langage commun qui permettra aux responsables de la
gestion de documents d'activité de collaborer avec les architectes d'entreprise afin de positionner
les exigences relatives à la gestion des documents d'activité dans le processus de développement de
l'architecture.
2 Références normatives
Le présent document ne contient aucune référence normative.
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s'appliquent.
L'ISO et l'IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l'adresse https: //www .iso .org/obp
— IEC Electropedia: disponible à l'adresse http: //www .electropedia .org/
3.1 Généralités
3.1.1
accès
droit, modalités et moyens de recherche, d'exploitation ou de récupération de l'information
[SOURCE: ISO 15489-1:2016, 3.1]
3.1.2
activité
tâche principale exécutée par une entité organisationnelle dans le cadre d'une fonction
[SOURCE: ISO 15489-1:2016, 3.2]
3.1.3
évaluation
étude des activités opérationnelles pour déterminer les documents d'activité qu'il est nécessaire de
créer et de capturer, ainsi que leur durée et moyen de conservation
Note 1 à l'article: Dans certaines méthodes de gestion des documents d'activité et des archives, l'évaluation
sert uniquement à déterminer les exigences en matière de conservation ou à créer un référentiel de gestion des
documents d'activité. Le concept d'évaluation tel qu'il est défini dans ce document est destiné à être utilisé de
manière plus large.
[SOURCE: ISO TR 21946: 2018, Introduction]
3.1.4
architecture
concepts fondamentaux ou propriétés d'un système dans son environnement incarnés dans
ses éléments, ses relations et dans les principes de sa conception et de son évolution
[SOURCE: ISO/IEC/IEEE 42010:2011, 3.2]
3.1.5
actif
tout élément représentant de la valeur pour l'organisme
Note 1 à l'article: Il peut exister plusieurs sortes d'actifs, dont:
a) l'information (par exemple les documents et les bases de données);
b) les logiciels, par exemple un programme informatique;
c) les actifs physiques, par exemple un ordinateur;
d) les services (c'est-à-dire la capacité de fournir quelque chose);
e) le personnel, et ses qualifications, compétences et expérience; et
f) les actifs incorporels, par exemple la réputation et l'image.
[SOURCE: ISO/IEC 27000:2009, 2.3]
2 © ISO 2019 – Tous droits réservés

3.1.6
documents d'activité probants
quelle que soit leur forme ou leur structure, les documents d'activité constituent des preuves de l'activité
faisant autorité lorsqu'elles possèdent les caractéristiques d'authenticité, de fiabilité, d'intégrité et
d'utilisabilité
[SOURCE: ISO 15489-1:2016, 5.2.2.]
3.1.7
classification
identification systématique et/ou classement des activités et/ou des documents d'activité en catégories
suivant des conventions et méthodes structurées logiquement, ainsi que des règles de procédures
[SOURCE: ISO 15489-1:2016, 3.5]
3.1.8
système d'intérêt
intérêt envers un système qui concerne une ou plusieurs de ses parties prenantes (3.1.22)
Note 1 à l'article: Un sujet d'intérêt se rapporte à toute influence sur un système dans son environnement, y
compris les influences de développement, technologiques, commerciales, opérationnelles, organisationnelles,
politiques, économiques, juridiques, réglementaires, écologiques et sociales.
[SOURCE: ISO/IEC/IEEE 42010:2011, 3.7]
3.1.9
contexte d'un organisme
combinaison d'enjeux internes et externes pouvant avoir un effet sur l'approche d'un organisme en ce
qui concerne la détermination et la réalisation de ses objectifs
Note 1 à l'article: Les objectifs de l'organisme peuvent être liés à ses produits et services, ses investissements et
son comportement envers ses parties intéressées.
Note 2 à l'article: Le concept de contexte de l'organisme s'applique aussi bien aux organismes à but non lucratif ou
de service public qu'aux organismes à but lucratif.
Note 3 à l'article: En anglais, ce concept est souvent désigné par d'autres termes, tels que «environnement
commercial», «environnement de l'organisme» ou «écosystème d'un organisme».
Note 4 à l'article: Comprendre l'infrastructure peut aider à définir le contexte de l'organisme.
Note 5 à l'article: L'encapsulation des données reconnue par un expert du domaine d'activité comme représentant
un élément conceptuel pertinent pour le modèle de domaine de cette activité (les instances d'entités d'information
peuvent devenir des actifs d'information).
[SOURCE: ISO 9000:2015, 3.2.2, modifiée — La Note 5 à l'article a été ajoutée.]
3.1.10
sort final
série de processus associés à la mise en œuvre des décisions de conservation,
de destruction ou de transfert des documents d'activité, telles qu'explicitées dans le référentiel de
gestion des documents d'activité ou tout autre outil de référence
[SOURCE: ISO 15489-1:2016, 3.8]
3.1.11
preuve
information ou document prouvant une opération
Note 1 à l'article: Preuve d'une opération dont il peut être démontré qu'elle a été créée dans le cadre normal de
la conduite de l'activité de l'organisme et qu'elle est intacte et complète. Ne se limite pas au sens légal du terme.
[SOURCE: ISO 15489-1:2016, 3.10, modifiée]
3.1.12
fonction
ensemble d'activités qui assure les principales responsabilités en vue d'atteindre les objectifs
stratégiques d'une entité organisationnelle
[SOURCE: ISO 15489-1:2016, 3.11]
3.1.13
système de management
ensemble d'éléments corrélés ou en interaction d'un organisme, utilisés pour établir des politiques, des
objectifs et des processus de façon à atteindre lesdits objectifs
Note 1 à l'article: Un système de management peut traiter d'un seul ou de plusieurs domaines, par exemple
management de la qualité, gestion financière ou management environnemental.
Note 2 à l'article: Les éléments du système de management comprennent la structure, les rôles et responsabilités,
la planification, le fonctionnement de l'organisme, les politiques, les pratiques, les règles, les convictions, les
objectifs et les processus permettant d'atteindre ces objectifs.
Note 3 à l'article: Le périmètre d'un système de management peut comprendre l'ensemble de l'organisme, des
fonctions ou des sections spécifiques et identifiées de l'organisme, ou une ou plusieurs fonctions dans un groupe
d'organismes.
Note 4 à l'article: Il s'agit de l'un des termes communs et définitions de base pour les normes de systèmes de
management de l'ISO, donnés dans l'Annexe SL du Supplément ISO consolidé aux Directives ISO/IEC, Partie 1. La
définition initiale a fait l'objet d'une modification des Notes 1 à 3 à l'article.
[SOURCE: ISO 9000:2015, 3.5.3]
3.1.14
métadonnées de gestion des documents d'activité
informations structurées ou semi-structurées, qui permettent la création, la gestion et l'utilisation de
documents d'activité dans le temps, au sein de divers domaines et entre ces domaines
[SOURCE: ISO 15489-1:2016, 3.12]
3.1.15
référentiel de métadonnées
plan logique qui montre les relations entre les éléments de métadonnées, habituellement par
l'établissement de règles d'utilisation et de gestion des métadonnées qui portent en particulier sur la
sémantique, la syntaxe et la condition des valeurs (niveau d'obligation)
[SOURCE: ISO 23081-1:2017, 3.10]
3.1.16
migration
processus de déplacement de documents d'activité d'un service de gestion des
documents d'activité à un autre service, en conservant toutes les caractéristiques de ces documents
d'activité
Note 1 à l'article: Voir également les définitions de ce concept dans l'ISO 30300:2011, 3.3.8 et
l'ISO 15489-1:2016, 3.13.
3.1.17
type de modèle
conventions pour un type de modélisation
Note 1 à l'article: Exemples de types de modèles: schémas de flux de données, schémas de classes, réseaux de
Petri, bilans, organigrammes et modèles de transition d'état.
[SOURCE: ISO/IEC/IEEE 42010:2011, 3.9]
4 © ISO 2019 – Tous droits réservés

3.1.18
document(s) d'activité
informations créées, reçues et préservées comme preuve et actif (3.1.5) par une personne physique ou
morale dans l'exercice de ses obligations légales ou la conduite des opérations liées à son activité
Note 1 à l'article: Le point de vue défini dans ce document se veut utile dans tout scénario d'architecture
d'entreprise et vise à prévenir les conflits de sens dans les multiples points de vue. Le terme utilisé dans
la modélisation ArchiMate de ce point de vue est «document métier». Dans le présent document, le terme
«document d'activité opérationnel» a la même définition que celle qui a été établie pour «document d'activité»
dans le domaine de la gestion des documents d'activité.
[SOURCE: ISO 15489-1:2016, 3.14, modifiée — La Note 1 à l'article a été ajoutée.]
3.1.19
gestion des documents d'activité
champ de l'organisation et de la gestion en charge d'un contrôle efficace et systématique de la création,
de la réception, de la conservation, de l'utilisation et du sort final (3.1.10) des documents d'activité, y
compris des processus de capture et de préservation de la preuve et de l'information liées aux activités
et aux opérations sous la forme de documents d'activité
[SOURCE: ISO 15489-1:2016, 3.15]
3.1.20
capacité de gestion des documents d'activité
capacité d'atteindre les objectifs en matière de gestion des documents d'activité (3.1.19)
3.1.21
système documentaire
système d'information qui intègre, organise, gère et rend possible l'accès (3.1.1) aux documents d'activité
(3.1.18) au fil du temps
Note 1 à l'article: Dans le contexte de la gestion des documents d'activité, le terme «système» désigne un système
métier qui est responsable de l'automatisation des activités et des opérations métier.
[SOURCE: ISO 15489-1:2016, 3.16, modifiée — Dans la définition, «dans le temps» a été remplacé par
«au fil du temps» et la Note 1 à l'article a été remplacée.]
3.1.22
partie prenante
personne, équipe, organisme ou catégorie de ces derniers, ayant un intérêt dans un système
Note 1 à l'article: Différentes parties prenantes ayant des rôles différents auront des sujets d'intérêt différents
[SOURCE: ISO/IEC/IEEE 42010:2011 3.10]
3.1.23
transaction
opération
plus petite unité d'un processus, qui consiste en un échange entre deux ou plusieurs participants ou
systèmes
[SOURCE: ISO 15489-1:2016, 3.18]
3.1.24
processus
une ou plusieurs séquences d'activités requises pour produire un résultat conforme aux règles de
gouvernance
Note 1 à l'article: Dans la version anglaise, la définition apporte une correction à l'ancienne, qui était «one or
more sequences of actions required to produce an outcome that complies with governing rules».
[SOURCE: ISO 15489-1:2016, 3.19]
3.2 Termes relatifs au TOGAF
NOTE La terminologie du TOGAF 9.2 est disponible en anglais à l'adresse: http: //pubs .opengroup
.org/architecture/togaf9 -doc/arch/chap03 .html
3.2.1
acteur
personne, organisme ou système ayant un ou plusieurs rôles qui initie des activités ou interagit avec elles
EXEMPLE Un commercial qui voyage pour rendre visite à des clients.
Note 1 à l'article: Un acteur peut être interne ou externe à un organisme. Dans l'industrie automobile, un
équipementier d'origine serait considéré comme un acteur par un concessionnaire automobile qui interagit avec
les activités de sa chaîne d'approvisionnement.
[SOURCE: TOGAF 9.2, 3.2, modifié]
3.2.2
principes d'architecture
déclaration d'intention qualitative devant être respectée par l'architecture
Note 1 à l'article: Les principes d'architecture sont un ensemble de principes qui se rapportent au travail
d'architecture. Ils reflètent un niveau de consensus au sein de l'entreprise et incarnent l'esprit et la pensée
des principes d'entreprise existants. Les principes d'architecture régissent le processus de développement
d'architecture, affectant le développement, la maintenance et l'utilisation de l'architecture d'entreprise.
[SOURCE: TOGAF 9.1, 3.16]
3.2.3
vue d'architecture
représentation d'un ensemble de sujets d'intérêt connexes
Note 1 à l'article: Les termes «vue» et «vue d'architecture» sont utilisés comme synonymes.
[SOURCE: TOGAF 9.2, 3.17]
3.2.4
point de vue d'architecture
spécification des conventions pour un type particulier de vue d'architecture (3.2.3)
Note 1 à l'article: Un point de vue d'architecture peut également être considéré comme la définition ou le schéma
de ce type de vue d'architecture. Il établit les conventions pour la construction, l'interprétation et l'utilisation
d'une vue d'architecture pour répondre à un sujet d'intérêt (ou à un ensemble de sujets d'intérêt) spécifique
concernant un système d'intérêt.
Note 2 à l'article: Les termes «point de vue» et «point de vue d'architecture» sont utilisés comme synonymes.
[SOURCE: TOGAF 9.2, 3.18]
3.2.5
capacité
aptitude que possède un organisme, une personne ou un système
EXEMPLE Marketing, contact client ou télémarketing sortant.
[SOURCE: TOGAF 9.2, 3.30]
3.2.6
architecture des données
description de la structure et de l'interaction des principaux types et sources de données de l'entreprise,
des actifs de données logiques et physiques, et des ressources de gestion des données
Note 1 à l'article: Les entités de données logiques peuvent être liées à des applications, des référentiels et des
services et peuvent être structurées en fonction de considérations de mise en œuvre.
6 © ISO 2019 – Tous droits réservés

Note 2 à l'article: Le concept de “données” n'est volontairement pas défini ici car il est sous-jacent à la définition
de l'architecture des données pour chaque scénario d'application. Il est fonction des exigences spécifiques du
scénario considéré.
[SOURCE: TOGAF 9.2, 3.36]
3.2.7
métamodèle
modèle qui décrit comment et avec quels concepts l'architecture sera décrite de façon structurée
[SOURCE: TOGAF 9.2, 3.50]
3.2.8
rôle
fonction habituelle ou attendue d'un acteur (3.2.1), ou rôle que quelqu'un ou quelque chose joue dans
une action ou un événement spécifique
Note 1 à l'article: Se définit également comme le rôle que joue un individu dans un organisme et la contribution
qu'ils apportent par l'utilisation de leurs compétences, connaissances, expérience et capacités.
Note 2 à l'article: Un acteur peut avoir plusieurs rôles.
[SOURCE: TOGAF 9.2, 3.31]
3.2.9
architecture de solution
description d'une opération ou d'une activité (3.1.2) délimitée et précise ainsi que de la manière dont le
service d'information et la technologie de l'information soutiennent cette opération
Note 1 à l'article: Une architecture de solution s'applique généralement à un seul projet ou à une seule version de
projet, ce qui aide à traduire les exigences en une vision de solution, en spécifications métier et/ou de système
informatique de haut niveau et en un portefeuille de tâches de mise en œuvre.
[SOURCE: TOGAF 9.2, 3.69]
4 Objectif du point de vue de la gestion des documents d'activité et vue
d'ensemble du contenu
4.1 Objectif du point de vue de la gestion des documents d'activité
Le principal domaine d'application de ce point de vue est l'aspect motivationnel avec les couches de
stratégie et MODE business, mais avec des considérations pour les couches d'application et de mise
en œuvre.
Le Tableau 1 résume ce point de vue, qui est défini ci-dessous à l'aide des artefacts modèles suivants:
— Tableau 2: Matrice cartographique des parties prenantes pour la Gestion des documents d'activité
principaux;
— Figure 3: Vue Information sur la gestion des documents d'activité (diagramme ArchiMate);
— Figure 4: Vue Information sur la gestion des documents d'activité (diagramme de classes UML);
— Figure 5: Vue Business Motivation (motivation opérationnelle) de la gestion des documents
d'activité — Objectifs (diagramme ArchiMate);
— Figure 6: Vue Business Motivation (motivation opérationnelle) de la gestion des documents
d'activité — Capacité (diagramme ArchiMate);
— Figure 8: Vue Motivation pour la gestion des documents d'activité — Principes d'architecture
(diagramme ArchiMate);
— Figure 9: Scénarios d'application de référence pour la Gestion des documents d'activité (diagramme
ArchiMate);
— Figure 10: Vue Stratégie de gestion des documents d'activité et implémentation (diagramme
ArchiMate).
Tableau 1 — Description du point de vue de la gestion des documents d'activité
Point de vue de la gestion des documents d'activité
Parties — Architecte d'entreprise
prenantes
— Responsable de la gestion des documents d'activité (en tant qu'architecte de domaine
de motivation spécifique)
— Architecte de processus (pour identifier les activités de transaction)
— Architecte de domaine (pour identifier les documents d'activité opérationnels et
les métadonnées des documents d'activité)
— Analyste opérationnel (pour déterminer les exigences en matière de conformité)
a
— Responsable de niveau C
Sujets — Stratégie et tactiques d'architecture
d'intérêt
— Motivation (ArchiMate définit les éléments de motivation comme suit: Valeur, Signification,
Moteur, Évaluation, Objectif, Résultat, Principe et Exigences. Ce point de vue se concentre
sur les éléments Principe et Exigences, tels qu'identifiés dans la base de connaissances de
la gestion des documents d'activité)
— Responsabilités (collaboration avec les responsables de la gestion de documents d'activité)
Objectifs — Conception
— Décision
— Information
Domaine — Aspect Motivation
d'application
— Couches multiples (Stratégie, Métier, Application et Implémentation)
a
Les postes de direction de haut rang au sein d'un organisme, qui sont généralement considérés comme les postes les plus
puissants et les plus influents d'un organisme, qui établissent la stratégie et prennent des décisions à enjeux élevés. Voici des
exemples courants de ces postes: Président-Directeur général (PDG), Directeur administratif et financier (DAF), Dirigeant
principal de l'information (DPI), Responsable principal de la sécurité, Chef de la sécurité de l'information, Directeur des
ressources humaines, Responsable de la conformité, etc. Parce qu'elles ne sont pas pertinentes pour la définition de ce point
de vue, les relations éventuelles entre les cadres supérieurs et les autres catégories de parties prenantes du «Responsable
de programmation» et du «Responsable de la gestion des documents d'activité» sont ici intentionnellement ignorées (dans
un scénario réel, elles pourraient dépendre de chaque structure organisationnelle particulière).
4.2 Point de vue de la gestion des documents d'activité et méthode ADM
La gestion des documents d'activité n'a pas besoin d'être traitée comme un domaine d'architecture à
part entière. Ses sujets d'intérêt peuvent tous s'exprimer dans les exigences relatives aux principaux
domaines et phases de l'architecture de l'ADM proposées dans le TOGAF.
L'Article 12 explique comment le point de vue de la gestion des documents d'activité peut être aligné sur
celui de l'ADM. L'Annexe C fournit plus de détails à cette fin.
8 © ISO 2019 – Tous droits réservés

5 Vue: Contexte opérationnel et parties prenantes de la gestion des documents
d'activité
5.1 Gestion des documents d'activité dans le contexte opérationnel
L'ISO 23081-1:2017, 9.1 et la Figure 1 montrent que les documents d'activité sont classés selon leur
contexte opérationnel.
Les organismes sont des systèmes socio-techniques, en ce sens qu'il s'agit de lieux de travail où des
personnes interagissent avec la technologie. Les contextes opérationnels sont des organisations
qui sont communément comprises comme des processus, de l'information, de la technologie et des
personnes qui sont censés interagir les uns avec les autres et avec leur environnement à l'appui d'un
objectif d'activité commun.
Le contexte dans lequel les activités se déroulent est défini par des missions, qui peuvent être soit
externes (lois, règlements, normes, etc.), soit internes (politiques, responsabilités, délégations, etc.).
Dans le cours des activités, les documents d'activité constituent la preuve documentée de la façon dont
les activités sont menées, ce qui permet de rendre compte de l'exécution des missions. De cette façon, la
gestion des documents d'activité est intégrée dans l'activité.
1)
Figure 1 — Gestion des documents d'activité et contexte opérationnel
La Figure 1 montre les relations entre l'activité, l'agent (équivalent d'un acteur TOGAF) et les entités
«documents d'acti
...