GB922-E Information Framework (SID) Model in Excel R14.0

Information Framework (SID)

GB922 Addendum E - Information Framework Model in Excel File Version 1.2

May, 2014

TM Forum 2014

Level 1 – Confidential

el in Excel File


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, th East Tower – 10 Floor, Morristown, NJ 07960 USA Tel No. +1 973 944 5100 Fax No. +1 973 944 5110 TM Forum Web Page: www.tmforum.org


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 as follows: Column A - Domain name /isABE name - appears once per domain / ABE. All rows below this one with empty column A belong the same ABE. Column B - Entity name to - appears once per entity. All attributes with empty entity name below each entity belong to the entity above them. C - Attribute origin name,-the of thedefines attributes entity If this field includes a different entity than Column D thenames entity which theper 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


ABE 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


Entity name

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


Attribute name


Attribute origin


severity ID interactionDate description

PartyProblem BusinessInteraction BusinessInteraction BusinessInteraction

interactionDateComplete interactionStatus

BusinessInteraction BusinessInteraction

name description

KnownProblemDescription KnownProblemDescription

closeDate ID summary

ClosePartyProblemSummary ClosePartyProblemSummary ClosePartyProblemSummary

partyProblemAttachment name description

PartyProblemWorkaround PartyProblemWorkaround PartyProblemWorkaround

creationDate dueDate status ID

PartyProblemTask PartyProblemTask PartyProblemTask PartyProblemTask


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).


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. It’s 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.


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. 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.




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 from each other.

ed, Rejected




eraction is taking place.

ed by a permanent one.


ABE 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


Entity name

Attribute name


Attribute origin

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. It’s 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.


ABE 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


Entity name

Attribute name


Attribute origin

Documentation


ABE 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


Entity name

Attribute name


Attribute origin

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.


ABE name Enterprise Domain Enterprise Risk ABE Enterprise Effectiveness ABE Workforce ABE


Entity name

Attribute name


Attribute origin

Documentation


ABE 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


Entity name

Attribute name


Attribute origin

Documentation


ABE 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


Entity name

Attribute name


Attribute origin

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).


ABE name

Resource Domain

Resource Specification ABE Resource Usage ABE Resource ABE Resource Performance ABE Resource Trouble ABE

Resource Configuration ABE


Entity name

Attribute name


Attribute origin

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).


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



Attribute name

Attribute origin

ID

ConfigurationSpecification

name description

ConfigurationSpecification ConfigurationSpecification

version validFor

ConfigurationSpecification ConfigurationSpecification

version description validFor

Configuration Configuration Configuration


dateCreated


Configuration

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.


ABE name Supplier_Partner Domain SupplierPartner ABE SP Agreement ABE SP Community ABE


Entity name

Attribute name


Attribute origin

Documentation


GB922-E Information Framework (SID) Model in Excel R14.0

Recommend Documents