Information Framework (SID)

GB922 Addendum E - Information Framework Model in Excel File

Version 1.2

May, 2014
TM Forum 2014
Level 1 Confidential
GB922 Addendum E - Information Framework Model 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.
Direct inquiries to the TM Forum office:
240 Headquarters Plaza,
East Tower 10
th
Floor,
Morristown, NJ 07960 USA
Tel No. +1 973 944 5100
Fax No. +1 973 944 5110
TM Forum Web Page: www.tmforum.org
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 model structure is provided in 2 forms:
the SID14.0-Full includes the entire SID (excluding diagram packages and instances)
The other tabs include the SID broken into domains
For the user convenience the model can be collapsed or expanded using the "+" signs on the left of the
doc, by domain and L1 ABEs
The structure of the report is as follows: Column A - Domain name / ABE name - appears once per domain / ABE. All rows below this one with
empty column A belong to the same ABE. Column B - Entity name - appears once per entity. All attributes with empty entity name below each entity
belong to the entity above them.
Column C - Attribute name, the names of the attributes per entity Column D - Attribute origin - the entity which defines the attribute. If this field includes a different entity than
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
Configuration and Profiling ABE
TIP Common ABE
Catalog ABE
Trouble or Problem ABE
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
Engaged Party Domain (PRELIMINARY)
Business Interaction ABE
Agreement ABE
Party ABE
Party Order ABE
Party Interaction ABE
Additional Party Entities 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.
The Metric ABE defines a pattern to standardize the description of Metrics.
Its in vision that other projects use and specialize the Metric ABE in some way (creating sub-classes and adding
new entities) such as PM (Performance Management), RA (Revenue Assurance), SLA (Service Level Agreement),
etc.
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 CSP (typically through some analytics system)
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 that explains the interaction and details about an interaction, such as why an interaction is taking place.
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
Atextexplainingtheproblemanditspossiblesources
Records the closure activity of a PartyProblem. There may be more than one ClosePartyProblemSummary per PartyProblem because PartyProblems can be reopened, or a temporary solution may be replaced by a permanent one.
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.
Short readable name for the workaround
A text explaining the workaround for the known problem.
a trackable task delegated from the PartyProblem with a specified due date
The date and time in which the PartyProblemTask was created
The date and time in which the PartyProblemTask should be completed
The current status of the task. Possible values (among others) are Waiting, In Process, Completed, Failed, Rejected
A unique identifier that enables different instances of a PartyProblemTask to be distinguished from each other.
Level 1 Confidential
Level 1 Confidential
Level 1 Confidential
Represents a problem which affects the Party experience. PartyProblem can be raised by the Party (a complaint) or by the CSP (typically through some analytics system)
Narrative that explains the interaction and details about the interaction, such as why the interaction is taking place.Narrative that explains the interaction and details about an interaction, such as why an interaction is taking place.
A description of a known problem, optionally with some known workarounds. It may be shared by multiple PartyProblems.
Records the closure activity of a PartyProblem. There may be more than one ClosePartyProblemSummary per PartyProblem because PartyProblems can be reopened, or a temporary solution may be replaced by a permanent one.
A unique identifier that enables different instances of a ClosePartyProblemSummary to be distinguished from each other.
The current status of the task. Possible values (among others) are Waiting, In Process, Completed, Failed, Rejected
Level 1 Confidential
Level 1 Confidential
Level 1 Confidential
Narrative that explains the interaction and details about the interaction, such as why the interaction is taking place.Narrative that explains the interaction and details about an interaction, such as why an interaction is taking place.
Records the closure activity of a PartyProblem. There may be more than one ClosePartyProblemSummary per PartyProblem because PartyProblems can be reopened, or a temporary solution may be replaced by a permanent one.
Level 1 Confidential
ABE name Entity name
Common Business Entities Domain
Configuration and Profiling ABE
TIP Common ABE
Catalog ABE
Trouble or Problem ABE
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.
The Metric ABE defines a pattern to standardize the description of Metrics.
Its in vision that other projects use and specialize the Metric ABE in some way (creating sub-classes and adding
new entities) such as PM (Performance Management), RA (Revenue Assurance), SLA (Service Level Agreement),
etc.
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
Engaged Party Domain (PRELIMINARY)
Business Interaction ABE
Agreement ABE
Party ABE
Party Order ABE
Party Interaction ABE
Additional Party Entities ABE
Party Service Level Agreement ABE
Party Statistic ABE
Applied Party Billing Rate ABE
Party Bill ABE
Party Bill Collection ABE
Party Problem ABE
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
Product Configuration 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
Resource Specification ABE
Resource Usage ABE
Resource ABE
Resource Performance ABE
Resource Trouble ABE
Resource Configuration ABE
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
Service Specification ABE
Service Usage ABE
Service Performance ABE
TIP Service Management ABE
Service Configuration 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