Category: (1) TAM Application Type
Application Identifier: 6.2
Maturity Level: 4
Service Inventory Management represents the applications which contain and maintain information about the instances of services in a telecom organization.
A Service Inventory application may store and manage any or all of the following entities:
The Service Inventory may also store and manage service relationships:
This mapping is stored either intrinsically in the core Service Inventory, or discretely via Service-Supporting Resource Inventory applications.
Service
Inventory may include the following relationship types between entity
instances:
·
Realization by
Composition – A mapping from a service to the child services and/or resources
which specifically compose that service (e.g. the RFS instance or instances
whose whole purpose is to implement a CFS, the assignable resources which
realize an RFS). If a parent service is torn down, child objects with a
Composition relationship are typically removed or reallocated (e.g. transitioned
to spares inventory).
·
Realization by
Aggregation – A mapping from a service to the services and/or resources which
support this service in addition to other services. (e.g. a network access RFS
which supports a number of different network CFSes). If a parent service is torn
down, child objects with an Aggregation relationship are typically maintained as
long as at least one other parent service still exists.
· Dependency – A link between services and/or resources which is not strong enough to qualify as Composition or Aggregation, but where various Fulfillment, Assurance, and Change Management processes need to be aware of the relationship. Dependency relationships support the ability for change management processes to evaluate if a dependent service or resource may be impacted by changes to a specific service or resource.
Service Inventory Information
Model
This function is the underlying information model
for the service instances to be managed. The model serves as the foundation for
the data itself and a guiding force for the definition and modelling of new
services.
The Service Inventory Information Model should
evolve in close coordination with the Service Specification data model, since
the Service Inventory model must be able to store instances designed in
accordance with all the service specifications defined via the Service
Specification Management system.
Typically, the service provider would need to add a lot of detail concerning the services to be managed. The suggested approach for the service provider is to start with the TM Forum SID service model and then specialize the model for the specific services to be managed. The service model should indicate or point to the supporting component services and resources for each service (the SID model, in fact, does do this).
Service Inventory Retrieval
This
function allows for client system to retrieve a part or all of the service
inventory known to the Service Inventory Management
system.
This feature
may support the following selection criteria:
·
retrieval of only the
object instances that have been modified after a provided date and
time
·
retrieval based on
relationship to a specific entity (e.g. all CFS instances supported by a
specific RFS instance)
For the
selected objects, this feature may allow the client OSS to specify what specific
attributes and relationships shall be returned.
Service Inventory Update Notifications
This
function entails the generation of inventory update notifications based on
changes to the inventory known to the Service Inventory Management system. The
notification types typically include object creation, object deletion, attribute
value changes, and object relationship changes.
Single
Entity Notifications – in this variation of the feature, each notification
pertains to only one entity, e.g., an IP VPN service
instance
Multi-entity
Notifications – in this variation of the feature, a single notification may
report on inventory changes for multiple entities (e.g. changes in any component
services of a specific CFS).
This function entails an external system requesting that the Service Inventory Management system update its inventory based on a provided collection of updates. The expectation is that the Service Inventory Management system update its inventory as requested, but no other side-effects are expected (e.g., creating a service in the network). This is a key point concerning this capability. The inventory update request can involve creation of an object, deletion of an object, or modification of an object’s attributes, or creation or deletion of an object’s relationships to other objects.
Consumed
Contracts
Exposed
Contracts
This was created from the Frameworx 16.0 Model