Professional Documents
Culture Documents
GB922 E Information Framework SID Model in Excel R14 0 PDF
GB922 E Information Framework SID Model in Excel R14 0 PDF
May, 2014
Level 1 – Confidential
el in Excel File
Level 1 – Confidential
Notice
Copyright © TeleManagement Forum 2013. All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that
comment on or otherwise explain it or assist in its implementation may be prepared, copied, published,
and distributed, in whole or in part, without restriction of any kind, provided that the above copyright
notice and this section are included on all such copies and derivative works. However, this document
itself may not be modified in any way, including by removing the copyright notice or references to TM
FORUM, except as needed for the purpose of developing any document or deliverable produced by a
TM FORUM Collaboration Project Team (in which case the rules applicable to copyrights, as set forth in
the TM FORUM IPR Policy, must be followed) or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be revoked by TM FORUM
or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and TM
FORUM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Level 1 – Confidential
This document stands as an Addendum to the Information Framework (SID), GB922 Release 14.0.
Although not itself a core standard, it provides a report on model structure, entities and attributes (including
derived attribute) and can be used as a reference to the model and as a check list for model conformance
reports.
The structure
Column of the report
A - Domain name /isABE
as follows:
name - appears once per domain / ABE. All rows below this one with
empty column
Column A belong
B - Entity name to the same
- appears ABE.
once per entity. All attributes with empty entity name below each entity
belong to the entity above them.
Column D C - Attribute origin
name,-the
thenames of thedefines
entity which attributes
theper entity If this field includes a different entity than
attribute.
current entity it means that this is a derived attribute and the entity which appears in column D is a base
class of the current entity.
Column E - The description of the Domain/ABE/Entity/Attribute as appears in the model
Level 1 – Confidential
ABE name Entity name
Supplier_Partner Domain
Service Domain
Resource Domain
Engaged Party Product Domain
Market_Sales Domain
Enterprise Domain
Customer Domain
Common Business Entities Domain
Level 1 – Confidential
Policy ABE
Root Business Entities ABE
Base Types ABE
Location ABE
Project ABE
Calendar ABE
Usage ABE
Trouble Ticket ABE
Performance ABE
Capacity ABE
Users and Roles ABE
Metric ABE
Level 1 – Confidential
Party Service Level Agreement ABE
Party Statistic ABE
Applied Party Billing Rate ABE
Party Bill ABE
Party Bill Collection ABE
Party Problem ABE
PartyProblem
KnownProblemDescription
ClosePartyProblemSummary
PartyProblemWorkaround
PartyProblemTask
Level 1 – Confidential
Attribute name Attribute origin
Level 1 – Confidential
Level 1 – Confidential
severity PartyProblem
ID BusinessInteraction
interactionDate BusinessInteraction
description BusinessInteraction
interactionDateComplete BusinessInteraction
interactionStatus BusinessInteraction
name KnownProblemDescription
description KnownProblemDescription
closeDate ClosePartyProblemSummary
ID ClosePartyProblemSummary
summary ClosePartyProblemSummary
partyProblemAttachment PartyProblemWorkaround
name PartyProblemWorkaround
description PartyProblemWorkaround
creationDate PartyProblemTask
dueDate PartyProblemTask
status PartyProblemTask
ID PartyProblemTask
Level 1 – Confidential
Documentation
The Service Domain consists of a set of layered ABEs that are used to manage the definition, development, and
operational aspects of Services provided by an NGOSS system. Entities in this domain support various eTOM
processes that deal with the definition, development and management of services offered by an enterprise. This
includes Service Level Agreements, deployment and configuration of Services, management of problems in
Service installation, deployment, usage, or performance, quality analysis, and rating. Finally, this domain also
includes entities to perform planning for future offerings, service enhancement or retirement, and capacity .
The Resource Domain consists of a set of layered ABEs that are used to manage the definition, development, and
operational aspects of the information computing and processing infrastructure of an NGOSS system. It supports
the eTOM processes that deal with the definition, development and management of the infrastructure of an
enterprise. This includes the components of the infrastructure as well as Products and Services that use this
infrastructure.
The Resource Domain has three important objectives. The first is to associate Resources to Products and
Services, and provide a detailed enough set of Resource entities (organized as ABEs) to facilitate this association.
The second is to ensure that Resources can support and deliver Services offered by the enterprise. Management
of resources involves planning, configuration, and monitoring to capture performance, usage, and security
information. This also includes the ability to reconfigure Resources in order to fine tune performance, respond to
faults, and correct operational deficiencies in the infrastructure. Resources also provide usage information which
is subsequently aggregated to the customer level for billing purposes. The final objective of the Resource domain
is to enable strategy and planning processes to be defined. Entities in the Resource domain may be associated
with processes that involve planning new and/or enhanced Services, or even the retirement of Services, offered
by the Enterprise.
Add Policy ala what was done for pricing where values were the result of a condition being true...and others such
as using a Char for an operand in a condition...AbstractFor Composite/Atomic, Configuration targets
Configuration, Version History, and so forth.A Configuration (also referred to as a Profile) defines how a
Resource, Service, or Product operates or functions. A Configuration may contain one or more parts (which is
realized by using the Atomic/Composite pattern, but it is represented as a single entity -
ConfigurationRelationship), and each part may contain zero or more fields. Each field may have attributes that
are statically or dynamically defined. Some of these fields have fixed values, while others provide values from
which a choice or choices can be made (e.g., using the EntitySpec/Entity and/or
CharacteristicSpec/CharacteristicValue patterns).
Level 1 – Confidential
The Policy Domain consists of a set of layered ABEs that define specifications (e.g., templates) and definitions of
Policy entities that can be used in managing the behavior and definition of entities in other Domains. Policy takes
three primary forms. The first is the definition of how policy is used to manage the definition, change, and
configuration of other entities. The second is the definition of how policy itself is managed. The third is how
applications use policies to manage entities.
An Engaged Party is an individual or organization that may play one or more roles (out of the universe of all
parties and roles they play) that are of interest (competitors, sales prospects, and such), involved (customers,
users, and such), and that provide value directly or indirectly (service providers, operators, cloud brokers,
infrastructure providers, application developers, and such) from a provider/operator perspective.
The word “engaged” is important instead of just using the word “Party” for the domain. As noted in the
definition “(out of the universe of all parties and roles they play)” many parties exist in the “universe” which are
do not meet the qualifications specified in the definition. An individual or organization may not be of interest,
may not be involved, and may not provide value directly or indirectly. For example, individuals in a country in
which an enterprise does not operate may not satisfy the definition. So Engaged Party is a more precise
definition than Party in that engaged parties have some form of relationship with an enterprise.
Note: Customer is considered a special case of Engaged Party that is represented as a separate domain. The
same is true for Supplier/Party except that this domain may be merged with the Engaged Party domain in a
future release. Parties in other domains, such as the Workforce Resource ABE in the Enterprise domain /
Workforce ABE, are and will be modeled as ABEs or even entities in their respective domains/ABEs. All of the
core entities, such as Customer and Employee continue to inherit from (are subclasses of) the PartyRole entity.
Level 1 – Confidential
Represents a problem which affects the Party experience. PartyProblem can be raised by the Party (a complaint) or by the CS
The severity of the PartyProblem (in the eyes of the CSP).
Unique identifier for Interaction.
Date interaction initiated.
Narrative that explains the interaction and details about the interaction, such as why the interaction is taking place.Narrative
The date on which an interaction is closed or completed.
The current condition of an interaction, such as open, in research, closed, and so forth.
A description of a known problem, optionally with some known workarounds. It may be shared by multiple PartyProblems.
Short readable name for the known problem
A text explaining the problem and its possible sources
Records the closure activity of a PartyProblem. There may be more than one ClosePartyProblemSummary per PartyProblem b
The date in which the PartyProblem was closed
A unique identifier that enables different instances of a ClosePartyProblemSummary to be distinguished from each other.
A textual description of the solution applied to the PartyProblem
a resolution (sometimes temporary) for a KnownProblemDescription.
Level 1 – Confidential
Level 1 – Confidential
Level 1 – Confidential
complaint) or by the CSP (typically through some analytics system)
s taking place.Narrative that explains the interaction and details about an interaction, such as why an interaction is taking place.
ltiple PartyProblems.
mary per PartyProblem because PartyProblems can be reopened, or a temporary solution may be replaced by a permanent one.
ed, Rejected
Level 1 – Confidential
Level 1 – Confidential
Level 1 – Confidential
eraction is taking place.
ed by a permanent one.
Level 1 – Confidential
ABE name Entity name
Common Business Entities Domain
Policy ABE
Root Business Entities ABE
Base Types ABE
Location ABE
Project ABE
Calendar ABE
Usage ABE
Trouble Ticket ABE
Performance ABE
Capacity ABE
Users and Roles ABE
Metric ABE
Level 1 – Confidential
Attribute name Attribute origin
Level 1 – Confidential
Documentation
Add Policy ala what was done for pricing where values were the result of a condition being true...and others such
as using a Char for an operand in a condition...AbstractFor Composite/Atomic, Configuration targets
Configuration, Version History, and so forth.A Configuration (also referred to as a Profile) defines how a
Resource, Service, or Product operates or functions. A Configuration may contain one or more parts (which is
realized by using the Atomic/Composite pattern, but it is represented as a single entity -
ConfigurationRelationship), and each part may contain zero or more fields. Each field may have attributes that
are statically or dynamically defined. Some of these fields have fixed values, while others provide values from
which a choice or choices can be made (e.g., using the EntitySpec/Entity and/or
CharacteristicSpec/CharacteristicValue patterns).
The Policy Domain consists of a set of layered ABEs that define specifications (e.g., templates) and definitions of
Policy entities that can be used in managing the behavior and definition of entities in other Domains. Policy takes
three primary forms. The first is the definition of how policy is used to manage the definition, change, and
configuration of other entities. The second is the definition of how policy itself is managed. The third is how
applications use policies to manage entities.
Level 1 – Confidential
ABE name Entity name
Customer Domain
Customer Order ABE
Customer Interaction ABE
Customer ABE
Customer Service Level Agreement ABE
Customer Statistic ABE
Applied Customer Billing Rate ABE
Customer Bill ABE
Customer Bill Collection ABE
Customer Problem ABE
Level 1 – Confidential
Attribute name Attribute origin
Level 1 – Confidential
Documentation
Level 1 – Confidential
ABE name Entity name
Level 1 – Confidential
Attribute name Attribute origin
Level 1 – Confidential
Documentation
An Engaged Party is an individual or organization that may play one or more roles (out of the universe of all
parties and roles they play) that are of interest (competitors, sales prospects, and such), involved (customers,
users, and such), and that provide value directly or indirectly (service providers, operators, cloud brokers,
infrastructure providers, application developers, and such) from a provider/operator perspective.
The word “engaged” is important instead of just using the word “Party” for the domain. As noted in the
definition “(out of the universe of all parties and roles they play)” many parties exist in the “universe” which are
do not meet the qualifications specified in the definition. An individual or organization may not be of interest,
may not be involved, and may not provide value directly or indirectly. For example, individuals in a country in
which an enterprise does not operate may not satisfy the definition. So Engaged Party is a more precise
definition than Party in that engaged parties have some form of relationship with an enterprise.
Note: Customer is considered a special case of Engaged Party that is represented as a separate domain. The
same is true for Supplier/Party except that this domain may be merged with the Engaged Party domain in a
future release. Parties in other domains, such as the Workforce Resource ABE in the Enterprise domain /
Workforce ABE, are and will be modeled as ABEs or even entities in their respective domains/ABEs. All of the
core entities, such as Customer and Employee continue to inherit from (are subclasses of) the PartyRole entity.
Level 1 – Confidential
ABE name Entity name
Enterprise Domain
Enterprise Risk ABE
Enterprise Effectiveness ABE
Workforce ABE
Level 1 – Confidential
Attribute name Attribute origin
Level 1 – Confidential
Documentation
Level 1 – Confidential
ABE name Entity name
Market_Sales Domain
Market Segment ABE
Market Strategy Plan ABE
Sales Channel ABE
Competitor ABE
Contact_Lead_Prospect ABE
Sales Statistics ABE
Marketing Campaign ABE
Level 1 – Confidential
Attribute name Attribute origin
Level 1 – Confidential
Documentation
Level 1 – Confidential
ABE name Entity name
Engaged Party Product Domain
Product Specification ABE
Product Offering ABE
Product ABE
Strategic Product Portfolio Plan ABE
Product Usage ABE
Loyalty ABE
Level 1 – Confidential
Attribute name Attribute origin
Level 1 – Confidential
Documentation
A loyalty program is one of the tools used by the loyalty process to retain customers.
The Loyalty ABE contains all entities useful to specify and instantiate loyalty programs.
A LoyaltyProgramProdSpec defines the LoyaltyRules that have to be checked in order to identify the actions to
apply.
Depending on the type of LoyaltyRules a LoyaltyAccount might be needed to collect gains or not.
A LoyaltyProgramProduct is a type of ProductComponent and described by a LoyaltyProgramProdSpec.
The definition of how a Product operates or functions in terms of CharacteristicSpecification(s) and related
ResourceSpec(s), ProductSpec(s), ServiceSpec(s) as well as a representation of how a Product operates or
functions in terms of characteristics and related Resource(s), Product(s), Service(s).
Level 1 – Confidential
ABE name Entity name
Resource Domain
Level 1 – Confidential
Attribute name Attribute origin
Level 1 – Confidential
Documentation
The Resource Domain consists of a set of layered ABEs that are used to manage the definition, development, and
operational aspects of the information computing and processing infrastructure of an NGOSS system. It supports
the eTOM processes that deal with the definition, development and management of the infrastructure of an
enterprise. This includes the components of the infrastructure as well as Products and Services that use this
infrastructure.
The Resource Domain has three important objectives. The first is to associate Resources to Products and
Services, and provide a detailed enough set of Resource entities (organized as ABEs) to facilitate this association.
The second is to ensure that Resources can support and deliver Services offered by the enterprise. Management
of resources involves planning, configuration, and monitoring to capture performance, usage, and security
information. This also includes the ability to reconfigure Resources in order to fine tune performance, respond to
faults, and correct operational deficiencies in the infrastructure. Resources also provide usage information which
is subsequently aggregated to the customer level for billing purposes. The final objective of the Resource domain
is to enable strategy and planning processes to be defined. Entities in the Resource domain may be associated
with processes that involve planning new and/or enhanced Services, or even the retirement of Services, offered
by the Enterprise.
The Resource Specification ABE contains entities that define the invariant characteristics and behavior of each of
the four types of Resource entities. This enables multiple instances to be derived from a single specification
entity. In this derivation, each instance will use the invariant characteristics and behavior defined in its
associated template.
The definition of how a Resource operates or functions in terms of CharacteristicSpecification(s) and related
ResourceSpec(s), as well as a representation of how a Resource operates or functions in terms of characteristics
and related Resource(s).
Level 1 – Confidential
ABE name Entity name
Service Domain
Service Problem ABE
Service ABE
ServiceConfigSpec
ServiceConfiguration
Level 1 – Confidential
Level 1 – Confidential
Attribute name Attribute origin
ID ConfigurationSpecification
name ConfigurationSpecification
description ConfigurationSpecification
version ConfigurationSpecification
validFor ConfigurationSpecification
version Configuration
description Configuration
validFor Configuration
Level 1 – Confidential
dateCreated Configuration
Level 1 – Confidential
Documentation
The Service Domain consists of a set of layered ABEs that are used to manage the definition, development, and
operational aspects of Services provided by an NGOSS system. Entities in this domain support various eTOM
processes that deal with the definition, development and management of services offered by an enterprise. This
includes Service Level Agreements, deployment and configuration of Services, management of problems in
Service installation, deployment, usage, or performance, quality analysis, and rating. Finally, this domain also
includes entities to perform planning for future offerings, service enhancement or retirement, and capacity .
The Service Specification ABE contains entities that define the invariant characteristics and behavior of both
types of Service entities. This enables multiple instances to be derived from a single specification entity. In this
derivation, each instance will use the invariant characteristics and behavior defined in its associated template.
This ABE includes a third type of Service Specification entity: that of a ServiceLevelSpecification. This type of
specification templatizes Services that are bound to a Service Level Agreement.
Entities in this ABE focus on adherence to standards, distinguishing features of a Service, dependencies (both
physical and logical, as well as on other services), quality, and cost. In general, entities in this ABE enable Services
to be bound to Products and run using Resources.
Network services are one example of Services that can be built. Additional examples include installation,
maintenance, monitoring, and content authentication, authorization, accounting, and auditing functions.
The definition of how a Service operates or functions in terms of CharacteristicSpecification(s) and related
ResourceSpec(s) and ServiceSpec(s) as well as a representation of how a Product operates or functions in terms
of characteristics and related Resource(s) and Service(s).
The definition of how a Service operates or functions in terms of CharacteristicSpecification(s) and related
ResourceSpec(s) and ServiceSpec(s).
A unique identifier for the ConfigurationSpecification.
A word, term, or phrase by which the ConfigurationSpecification is known and distinguished from other
ConfigurationSpecifications.
A narrative that explains in detail what the ConfigurationSpecification is.
A particular form of a ConfigurationSpecification that differs in certain respects from an earlier
ConfigurationSpecification.
The period for which the ConfigurationSpecification is valid.
A representation of how a Service operates or functions in terms of characteristics and related Resource(s) and
Service(s).
A particular form of a Configuration that differs in certain respects from an earlier Configuration.
A narrative that explains in detail what the Configuration is.
The period for which the Configuration is valid.
Level 1 – Confidential
The date and time on which the Configuration was created.
Level 1 – Confidential
ABE name Entity name
Supplier_Partner Domain
SupplierPartner ABE
SP Agreement ABE
SP Community ABE
Level 1 – Confidential
Attribute name Attribute origin
Level 1 – Confidential
Documentation
Level 1 – Confidential