ISO/IEC TR 23951:2020
(Main)Information technology — Cloud computing — Guidance for using the cloud SLA metric model
Information technology — Cloud computing — Guidance for using the cloud SLA metric model
The scope of this document is to describe guidance for using the ISO/IEC 19086-2 metric model, illustrated with examples.
Technologies de l'information — Informatique en nuage — Recommandations pour l'utilisation du modèle métrique d'accord de niveau de service (SLA) dans le Cloud
General Information
Relations
Standards Content (Sample)
TECHNICAL ISO/IEC TR
REPORT 23951
First edition
2020-06
Information technology — Cloud
computing — Guidance for using the
cloud SLA metric model
Technologies de l'information — Informatique en nuage —
Recommandations pour l'utilisation du modèle métrique d'accord de
niveau de service (SLA) dans le Cloud
Reference number
©
ISO/IEC 2020
© ISO/IEC 2020
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
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2020 – All rights reserved
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 1
5 Structure of this document . 2
6 Motivation. 2
6.1 Preamble . 2
6.2 Audience and some user categories . 2
6.2.1 General. 2
6.2.2 Cloud service customer (CSC) . 3
6.2.3 Cloud service provider (CSP) . 3
6.2.4 Cloud service partner (CSN) . 3
6.2.5 Regulators and policy makers . 4
6.3 Usage patterns . 4
6.3.1 General. 4
6.3.2 Extract and clarify an existing metric description from an SLA . 4
6.3.3 Create and share a metric description . 4
6.3.4 Compare metric descriptions . 5
6.3.5 Share a common foundation for a set of metrics . 5
6.3.6 Build a metrics catalogue . 5
6.4 Examples of scenarios and roles involved in sharing metric definitions . 5
7 The metric model in practice: templates . 6
7.1 A brief reminder of the metric model . 6
7.2 A tabular representation . 7
7.2.1 General. 7
7.2.2 The tabular representation for the Metric element . 8
7.2.3 The tabular representation for the Expression elements . 9
7.2.4 The tabular representation for the Rule elements .10
7.2.5 The tabular representation for the Parameter elements .11
8 An example of metric definition: the cloud service mean response time metric .11
8.1 The cloud service mean response time metric: informal variant .11
8.1.1 Extracting metric elements from an SLA narrative .11
8.1.2 Using the tabular representation .12
8.1.3 Overall structure of the metric .14
8.2 The cloud service mean response time metric: more formal variant .14
8.2.1 A more formal variant of the metric .14
8.2.2 Adding a parameter .15
8.2.3 The metric rules .15
8.2.4 The metric expressions .15
8.2.5 Overall structure of the metric .17
8.2.6 Using constants .17
9 Guidelines for using the metric model with the tabular representation .19
9.1 General .19
9.2 Guideline 1 about defining expression and rule languages.20
9.3 Guideline 2 about associating rules with expressions .20
9.4 Guideline 3 about relating expressions to each other .20
9.5 Guideline 4 about the identifiers of metric elements .21
9.6 Guideline 5 about rules specifically designed to support an expression .21
9.7 Guideline 6 about the role of parameters .21
© ISO/IEC 2020 – All rights reserved iii
9.8 Guideline 7 about representing constants .22
10 The simple cloud service availability metric .22
10.1 Measuring cloud service availability .22
10.1.1 General.22
10.1.2 Overall design approach .23
10.1.3 SLA rules and metric rules .23
10.2 The simple cloud service availability metric variant Simple_SAM_1 .24
10.2.1 The Metric element .24
10.2.2 The metric rules .24
10.2.3 The metric expressions .25
10.2.4 The metric parameters .27
10.2.5 Overall structure of the metric .27
10.3 The simple cloud service availability metric variant Simple_SAM_2 .28
10.3.1 Differences in metric design and assumptions .28
10.3.2 The Metric element .29
10.3.3 The metric rules .29
10.3.4 The metric parameters .30
10.3.5 The metric expressions .31
10.3.6 Overall structure of the metric .32
10.3.7 An alternative metric design using the Configuration element option .32
Bibliography .34
iv © ISO/IEC 2020 – All rights reserved
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that
are members of ISO or IEC participate in the development of International Standards through
technical committees established by the respective organization to deal with particular fields of
technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with ISO and IEC, also
take part in the work.
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 document 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 and IEC 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) or the IEC
list of patent declarations received (see http:// patents .iec .ch).
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 Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 38, Cloud Computing and Distributed Platforms.
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.
© ISO/IEC 2020 – All rights reserved v
Introduction
In most cases, cloud service providers (CSPs) and cloud service customers (CSCs) negotiate service
level agreements (SLAs) which include service level objectives (SLOs) and service qualitative objectives
(SQOs) for which CSPs make commitments. The commitments described in SLAs are expected to be
measured against actual performance of the service to ensure compliance with the SLA. How actual
performance compares against commitments in SLAs is explained in ISO/IEC 19086-2. Cloud SLAs are
covered in ISO/IEC 19086-1 and in ISO/IEC 19086-4.
The metric model in ISO/IEC 19086-2 establishes common terminology, defines a model for specifying
metrics for cloud SLAs, and includes applications of the model with examples. This document provides
guidance and examples on using the metric model to compose the calculation of a cloud service
performance measure in order to compare against an SLA commitment. A few examples from the
SLOs listed in ISO/IEC 19086-1:2016, Clause 10 are given in the document, such as Cloud Service Mean
Response Time and Simple Cloud Service Availability. As specific, measurable characteristics of a cloud
service, SLOs are the basis for defining the metrics used to evaluate and compare agreements between
parties.
In Clauses 8, 9 and 10 of this document, a basic explanation of these examples is provided using a
practical method based on a tabular format that is a refinement of the informative tables provided
in ISO/IEC 19086-2:2018, Annex B. The tabular representation described in this document serves as
templates for designing metrics. Guidance in using the metric model with these templates is provided
while developing metric examples.
vi © ISO/IEC 2020 – All rights reserved
TECHNICAL REPORT ISO/IEC TR 23951:2020(E)
Information technology — Cloud computing — Guidance
for using the cloud SLA metric model
1 Scope
The scope of this document is to describe guidance for using the ISO/IEC 19086-2 metric model,
illustrated with examples.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 17788, Information technology — Cloud computing — Overview and vocabulary
ISO/IEC 17789, Information technology — Cloud computing — Reference architecture
ISO/IEC 19086-1, Information technology — Cloud computing — Service level agreement (SLA)
framework — Part 1: Overview and concepts
ISO/IEC 19086-2, Cloud computing — Service level agreement (SLA) framework — Part 2: Metric model
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 17788, ISO/IEC 17789,
ISO/IEC 19086-1 and ISO/IEC 19086-2 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/
4 Symbols and abbreviated terms
CCRA cloud computing reference architecture
CSC cloud service customer
CSN cloud service partner
CSP cloud service provider
SLA service level agreement
SLO service level objective
SQO service quality objective
© ISO/IEC 2020 – All rights reserved 1
5 Structure of this document
In supporting the scope presented in Clause 1, this document develops the rationale for a practical
metric representation to complement the metric model in ISO/IEC 19086-2 in the following clauses:
— Clause 6 states the rationale for complementing the metric model as defined in ISO/IEC 19086-2
with a practical representation and for providing related usage guidance as introduced by this
document. It identifies some usage patterns and highlights some usage scenarios where metric
definitions are shared across various parties. The users who benefit from this document include
parties with roles defined in ISO/IEC 17789 (Cloud computing — Reference architecture).
— Clause 7 introduces the tabular metric representation supportive of the metric model and derived
from the informative tables listed in ISO/IEC 19086-2:2018, Annex B. This representation is based on
tables intended to serve as templates for metric definitions. This clause represents initial guidance in
using the metric model, which is then illustrated and discussed throughout the examples developed
later in the document.
— Clause 8 introduces a simple case of metric definition that illustrates the use of the table templates
introduced in Clause 7. This example starts with the description of a metric as it would appear in
the narrative of an existing SLA and illustrates the extraction of this description toward a more
structured and distinct representation using the proposed tabular representation. The example
shows practical aspects when designing and developing metrics, such as how metric rules relate to
expressions, and how to parameterize rules and expressions.
— Clause 9 is a set of guidelines on how to use the metric model with the tabular templates (Clause 7).
This guidance is motivated and illustrated by the examples throughout the document. These
guidelines are best understood after developing a preliminary example (Clause 8). They explain how
to use the metric model with the tabular templates for metric use cases posing similar challenges or
using similar features.
— Clause 10 develops a more elaborate metric example for cloud service availability. It describes
two variants of the same metric that illustrate two different approaches in using the metric
model elements. Since it comes after the guideline items listed in Clause 9, it is easier to relate the
development of this second example to these guidelines.
6 Motivation
6.1 Preamble
This clause first identifies the audience of this document and for the tabular metric representation
described in this document. This clause then describes some metric usage patterns and then identifies
scenarios and roles for these metric usage patterns. Sharing common guidelines and conventions in
using the metric model improves the ability to reuse and compare metrics. These common guidelines
extend to the aspects of a metric that are part of the metric model but the details of which are out of
scope of the metric model in ISO/IEC 19086-2, such as the use of rule and expression languages and
how these constructs relate to each other. Supportive of the goal of harmonizing the usage of the metric
model across users, this document proposes a tabular representation for metric definitions that is
derived from and augments the tables provided in Annex B of the metric model in ISO/IEC 19086-2:2018,
as explained in 7.2.2.
6.2 Audience and some user categories
6.2.1 General
The audience for this document is expected to be diverse, as the metric representation proposed in
this document is intended for different parties involved in providing or using cloud services. However
not every clause is of interest to all. Those who read, negotiate or create SLA content, such as business
users and administrators, are expected to be interested in Clauses 1 to 7 and in the initial approach
2 © ISO/IEC 2020 – All rights reserved
to the first metric example (see 8.1). In addition to these clauses, metric designers and developers
are expected to be interested in the remaining clauses including more elaborate examples of metrics
(starting from 8.2 and beyond).
The parties interested in this document include representatives of the following roles defined in
ISO/IEC 17788.
6.2.2 Cloud service customer (CSC)
This document helps the CSC to understand the metrics used for service quality and other assurances
described in SLAs. When blended into the narrative of the SLA, metrics are often ambiguous or
incomplete. A structured definition as described in the metric model and made practical with a tabular
representation helps to avoid or at least detect such issues.
Specific types of customers are interested in understanding how a service is measured without having
to read the entire SLA or prior to establishing an SLA. These customers are defined in the CCRA as
a cloud service users (who uses a cloud service to fulfil her/his role), a service administrator (who
oversees all the operational processes relating to the use of cloud services, serving as intermediary
between the user and the provider) and a business manager (who has overall responsibility for the
business aspects of using cloud services, including the purchase of the service under appropriate terms
and possibly the request of audit reports).
The tabular representation in this document is also an analysis tool for the CSC to identify and extract
the metric material found in an SLA in order to get a clearer understanding of how the service is
measured, as illustrated in 8.1.
6.2.3 Cloud service provider (CSP)
This document helps the CSP to describe the service metrics that support his or her SLAs, potentially
avoiding contentious claims afterward that result from CSCs misunderstanding the terms and conditions
of these SLAs. It also helps providers to harmonize their metrics across data-centre operators or world
regions. Among activities expected from CSPs as defined in ISO/IEC 17789, the following are facilitated
by metric definitions and evaluations: monitoring service, administering service security, providing
audit data on request, defining and gathering metrics, managing security and risks, and, finally,
handling support requests, reports and incidents from cloud service customers. For these activities,
this document helps to establish a common and unambiguous representation of metrics used between
parties involved in these activities and distinct from other SLA material.
6.2.4 Cloud service partner (CSN)
The following CSN sub-roles are expected to find value in a metric definition template and guidelines:
— Cloud service developer: this user is responsible for designing, developing, integrating, testing,
and maintaining cloud services. Developers need to understand the measurements used to evaluate
a cloud service. This role includes composing a new cloud service from existing separate cloud
services. By having access to precise metric definitions and their rules, such as those illustrated in
Clauses 8 and 10, developers understand what features are to be monitored, what is the expected
quality of the developed cloud service and its priorities, as well as how to evaluate the quality and
risks when integrating third party cloud services.
— Cloud auditor: the auditor has the responsibility of conducting an audit of the provision and the use
of cloud services. A cloud audit typically covers operations, performance and security and examines
whether a specified set of audit criteria are met. By using metrics, the auditor understands or
communicates clearly the details of the measurements to perform. Such precision and clarity
are provided by a distinct and detailed metric representation, as illustrated in the two examples
developed in Clauses 8 and 10.
© ISO/IEC 2020 – All rights reserved 3
6.2.5 Regulators and policy makers
Several aspects of policy definition and enforcement concern measurable properties both about
the cloud service usage (including cloud service usage duration and times, volume and type of data
involved), and the cloud service performance (such as cloud service quality, elasticity and scalability,
availability and reliability). Other policies (such as those about trust and transparency, security
procedures, privacy) concern the relationship, governance and risk management between parties,
especially CSCs and CSPs. Whether these policies involve automated monitoring or some human
assessment instead, they rely on some form of measurement for tracking their implementation. See
ISO/IEC TR 22678 for more information regarding the development of policies that govern or regulate
cloud service providers (CSPs) and cloud services, and those policies and practices that govern the use
of cloud services in organizations.
The expression of policies and rules sometimes translates into predefined metric elements that are
expected to be used even when defining a customized metric. An example is of a policy that determines
the formula (metric expression) to be used when assessing cloud service uptime percentage, while
leaving other details unconstrained. As another example, if there is agreement for sharing across CSPs
the common definitions of “natural disaster” or “service misuse”, the reuse of such definitions helps to
establish a common understanding of what a valid cloud service downtime means. Creating and sharing
predefined metric material is a usage pattern described in 6.3.5 as sharing a metric foundation.
6.3 Usage patterns
6.3.1 General
A summary of various usage patterns for the tabular metric representation given in 7.2 and a rationale
for doing so are provided in the next subclauses. Some of these usage patterns match usage categories
identified in ISO/IEC 19086-2:2018, 6.4.2.
6.3.2 Extract and clarify an existing metric description from an SLA
Often, the metric(s) information in a cloud service SLA is scattered over the SLA narrative. Parts of
metric material (such as measurement rules, exceptions, underlying quantities and metrics) is mixed
with related information that is not part of the metric definition (such as performance objectives,
remediation measures and penalties).
Distinguishing a metric definition apart from its context of usage in an SLA and using for this the
metric model and its concrete representation helps detect ambiguities and missing elements. This also
promotes the reuse of a metric across SLAs and providers. (See 8.1 for an example of the extraction
of a metric definition from an SLA narrative). This pattern of using the tabular metric representation
supports the usage categories listed in ISO/IEC 19086-2:2018, 6.4.2.1 (cloud services) and 6.4.2.3 (cloud
service agreements).
6.3.3 Create and share a metric description
A metric definition is sometimes intended to be used by various parties including CSP, different CSCs
and CSNs including sub-roles such as cloud service developer and cloud auditor. Using a common metric
representation and its usage conventions helps these parties to describe and understand metrics that
they use and share.
A metric representation separate from an SLA helps different parties to share metrics while leaving
aside any other SLA content. Beyond an informal plain text description understandable by all, the
tabular representation introduced in 7.2 supports more formal descriptions such as specific languages
for the calculation logic (expressions) and its rules, thus serving different users. See 8.1 for using
different expression languages of interest to various parties. This pattern of using the tabular metric
representation supports usage categories listed in ISO/IEC 19086-2:2018, 6.4.2.1 (cloud services) and
6.4.2.4 (developing performance monitoring tools).
4 © ISO/IEC 2020 – All rights reserved
6.3.4 Compare metric descriptions
There are many variants of a seemingly common metric across CSPs. CSCs often want to compare
these. Such a comparison is made easier by using the same metric model and elements but also common
representation and guidelines. For example, significant variations have been observed between CSPs in
a metric as common as “service availability as uptime percentage” due to different definitions of cloud
service downtime.
A well-structured metric representation makes it easier to assess comparable metric elements.
This pattern of using the tabular metric representation supports usage categories listed in
ISO/IEC 19086-2:2018, 6.4.2.2 (comparing cloud services).
6.3.5 Share a common foundation for a set of metrics
In many cases, it is desirable to share the same metric conventions and elements, if not the same metric.
These conventions and elements are expressed as a partially developed metric definition, called a
metric foundation in this document for convenience. For example, a metric foundation can be defined
for cloud service availability that imposes the same general calculation of “availability” as cloud service
uptime percentage, leaving the details for each CSP to define (see 6.2.5 about policies requiring to use
predefined metric elements).
6.3.6 Build a metrics catalogue
A metrics catalogue collects metrics and their variants in specific areas, along with their association to
useful resources such as available implementations. This is of interest to CSPs or communities of CSNs
interested in sharing and reusing metric material.
A common metric representation and a set of conventions based on a shared metric model are a step
toward building a metrics catalogue. This also helps to create a catalogue of metric implementations of
interest to cloud service developers. Such catalogues in turn serve as resources for various parties to
search, select and reuse metrics or metric elements.
6.4 Examples of scenarios and roles involved in sharing metric definitions
Metrics may be used in various ways and for different purposes, and therefore may have different
measurement definitions. Consider that calculating car rental “availability” is different from calculating
“airline seat availability”. CSPs may even have different definitions for the same metric. For example,
some CSPs may exclude “planned maintenance outages” when calculating “availability”, while others
include “planned maintenance outages”.
Consider an enterprise or government agency that purchases an IaaS service for compute. The role it
plays for the IaaS provider is the CSC who consumes a compute service. The enterprise (or government
agency) develops customized (PaaS) services to be reused by others in the enterprise or agency. After
the PaaS services are deployed, its role is also of a PaaS CSP.
Application developers in the enterprise (or government agency) can use the PaaS to help develop the
business applications (SaaS) for the benefit of their own end-users or business customers. After the
SaaS services are deployed, the department that provides these services acts in the role of SaaS CSP.
Availability metrics are of interest to several roles and sub-roles with different perspectives and
concerns, as illustrated in Table 1.
© ISO/IEC 2020 – All rights reserved 5
Table 1 — The use of cloud service availability metrics across roles
Metric: Cloud Service availability
Role description Use case scenario for the metric Potential availability metrics of
interest
CSP – IaaS cloud What level of “cloud infrastructure compute Cloud infrastructure compute
compute service service availability” can the CSP commit to for availability
provider its customers?
CSN – cloud PaaS The PaaS developer needs to determine what PaaS availability, Cloud
service developer availability “targets” are reasonable when devel- infrastructure compute
oping and deploying their PaaS services (such as availability
APIs). Does the cloud infrastructure compute ser-
vice availability commitment from the CSP enable
PaaS availability intended targets to be met?
CSC – cloud PaaS The user needs to understand what availability SaaS availability,
service customer, as a “targets” they should require to satisfy their PaaS availability,
SaaS developer customer needs. Does the PaaS availability ena- Cloud infrastructure
ble SaaS availability targets to be met? Does the compute availability
“Cloud infrastructure compute service availabil-
ity” CSP commitment enable SaaS and/or PaaS
availability targets to be met?
SaaS customer What application service availability can be SaaS availability
expected by the application user?
Table 1 illustrates the rationale for a metric definition that takes into account a variety of usages and
accommodates a range of users. A way to ease the understanding of a metric definition across various
parties is to describe it using more than one language, as illustrated in Clause 8.
Table 1 also suggests requirements for metrics to build on each other or to extend each other. An
example is of an IaaS CSP who does not include connectivity as part of the availability calculation, while
other roles/sub-roles are affected by outages related to network connectivity (such as between the
CSNs, CSCs and the CSP) and want it to be part of their notion of availability. A more complete cloud
service availability metric could compose a metric already developed for measuring the quality of
network connectivity with an availability metric for the service itself.
Designing a metric for reusability makes it more versatile and supports a variety of usages and intents.
This concern is briefly discussed in design options for the examples (see 8.2.4.2 and 10.2.3.2) as well as
in guideline 6 about parameterization in 9.7.
7 The metric model in practice: templates
7.1 A brief reminder of the metric model
An overview of the metric model is provided in Figure 1 as it appears in ISO/IEC 19086-2 in the form of
an UML diagram.
6 © ISO/IEC 2020 – All rights reserved
Figure 1 — The metric model in ISO/IEC 19086-2
Each one of the four blocks in Figure 1 (Metric, Rule, Expression, Parameter) is also called a metric
element. A more detailed description of the metric elements and their attributes is provided in
ISO/IEC 19086-2.
The term Metric element (capitalized) is used to refer specifically to the element named Metric in the
UML diagram and the tabular representation of this element.
The term "metric element" is used generically to denote any element that is part of a metric, without
necessary reference to a particular element type (i.e., Metric, Expression, Rule, Parameter).
7.2 A tabular representation
7.2.1 General
A tabular rendering of the metric model usable as a set of templates for capturing the definition of a
particular metric is provided in Table 2, Table 3, Table 4 and Table 5. There is one table for each type
of metric element (Metric, Rule, Expression, Parameter). For example, the Metric table, once filled
with values, represents the definition of a Metric element. These templates are described in the next
subclauses.
In the Metric table, the associations between the Metric element and its constituents (Rule, Expression
and Parameter elements) are represented as references to these constituent elements using the id
attribute (see associated element fields in Table 2). Such associations are illustrated as solid lines in the
diagram of Figure 1.
There are other relationships between metric elements that are accounted for in the metric model in
ISO/IEC 19086-2 although not represented in the diagram of Figure 1. These relationships are instead
represented in ways that depend on the metric languages (ruleLanguage, expressionLanguage),
the description of which is out of scope of the metric model. These relationships are between metric
elements that depend on other metric elements. Examples of such dependencies are:
— An Expression element using another underlying Expression element to support its calculation.
— An Expression element referencing Rule elements that govern its calculation.
— An Expression element referencing another (underlying) Metric element of which it uses the output.
© ISO/IEC 2020 – All rights reserved 7
— A Rule element designed on purpose to support a particular Expression element and referencing
this element.
— Rule or Expression elements parameterized by some Parameter element.
These cross-element relationships are denoted in this document as “depends on” relationships, as they
indicate that an element is somehow depending on another element. Unlike the association relationships
shown in the Figure 1 diagram and given explicit representation in the tabular templates (see the
associated element fields in Table 1), the “depends on” relationships are indicated inside the value of
some fields of the tables (such as ruleStatement, expressionStatement, or note attributes) and have no
explicit support in the table templates themselves.
In other words, the “depends on” relationship representation is dictated by user-defined conventions,
such as those described in ruleLanguage and expressionLanguage, and becomes apparent in the values
given to these fields for a specific metric. In the tables for the metric examples of this document, it is
typically represented by a reference to the id of the element that is depended on. The “depends on”
relationship is represented by dashed arrows in the figures that give an overview of the structure of
each metric example, such as in Figure 2 in 8.1.3.
7.2.2 The tabular representation for the Metric element
A non-normative tabular representation for metrics and their elements is provided in Annex B of the
metric model in ISO/IEC 19086-2:2018. The tabular representation proposed in this document and used
in the examples is a refinement of this metric model that differs mostly in its layout. Differences and
their rationale are pointed out for each table.
The table for the Metric element in this document clearly separates two sets of fields and qualifies
explicitly their expected content, to avoid any confusion for users:
— The attributes (content: a value)
— The associated elements (content: a reference)
The right column in the table template of Table 2 contains as an informative reminder a brief account of
the field definition (derived from the one originally provided in ISO/IEC 19086-2) and its multiplicity
(number of possible occurrences for that field in the table).
When used in an actual metric definition, the attributes are given a value in the right column, while the
associated elements contain a reference to another metric element, meaning to another table or table
row in this tabular representation.
In several examples, the id attribute is reported in the header of the metric for easier identification (in
addition to or instead of appearing in the same way as any other attribute), as shown in Table 2.
Table 2 — Tabular representation for the Metric element
Metric (id)
attribute value
id (1.1) A unique identifier for the metric.
description (0.n) A description of the metric. A case where several instances of this attribute
are used is when descriptions are provided in multiple languages.
source (1.1) The individual or organization that created this metric definition.
scale (1.1) Classification of the type of measurement result when using the metric.
The value of scale is one of: nominal, ordinal, interval, or ratio.
category (0.1) A grouping of metrics of similar characteristics or intent (e.g. “cloud elas-
ticity” or “cloud service availability”) and sharing comparable expressions, rules
or parameters.
note (0.n) additional information about the metric and how to use it.
8 © ISO/IEC 2020 – All rights reserved
Table 2 (continued)
Metric (id)
associated element Reference
expression (0.1) id of the main expression of the metric (the expression of the calculation
of the metric). Expressions can reference other expression ids, metric ids, and
parameter ids.
This field represents a relationship to the main expression element (identified by
its id) described in a separate table (see the “Set of Expressions” table).
parameter (0.n) id of a parameter used by the metric. This field represents a relationship
to a parameter (identified by its id), described in a separate table (see the “Set of
Parameters” table).
rule (0.n) id of a rule used by the metric. This field represents a relationship to a rule
(identified by its id), described in a separate table (see the “Set of Rules” table).
underlyingMetric (0.n) id of another metric used in support of this metric.
This field represents a relationship to the underlying metric (identified by its id).
To each referenced underlying Metric corresponds a set of tables {Metric, Set of
Expressions, Set of Rules, Set of Parameters}.
underlyingExpression (0.n) id of an expression used in support of the main expression of
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...