Open APIs

A common process that is employed - both in Plan and Build, and in Order to Activation, is that of Assign and Design where individual resources are allocated to a design based on manual processes, automated processes applying business rules etc.

As this 'design' is usually carried out in a Resource Inventory function, but can be called from both Service Fulfilment and Network Rollout processes, there arises a need for a separate API that enables the configuration of the requested design, results in a completed design with reserved (or even allocated) resources in the Resource Inventory.

TMF652 is about ordering a specific resource, and is far too granular - and in any event - you STILL need a process to orchestrate all the resources that need to assigned, along with the associated designs around configuration or routing.

How do we go about proposing a new API that enables the request, progress reporting and result retrieval of this function? 

Hi Pieter,

your statement "this 'design' is usually carried out in a Resource Inventory" is from the past implementations (I have similiar experience) but as far as I understand TMF standards and guidelines "this design" should be implemented in Service Order Management ODA Component. I believe reason for this is that SOM is loosely coupled with Resource Inventory in this case, which is a good thing. But here are far more experienced guys and I'm currious what they will say about your idea.

A common process that is employed - both in Plan and Build, and in Order to Activation, is that of Assign and Design where individual resources are allocated to a design based on manual processes, automated processes applying business rules etc.

As this 'design' is usually carried out in a Resource Inventory function, but can be called from both Service Fulfilment and Network Rollout processes, there arises a need for a separate API that enables the configuration of the requested design, results in a completed design with reserved (or even allocated) resources in the Resource Inventory.

TMF652 is about ordering a specific resource, and is far too granular - and in any event - you STILL need a process to orchestrate all the resources that need to assigned, along with the associated designs around configuration or routing.

How do we go about proposing a new API that enables the request, progress reporting and result retrieval of this function? 

Thanks Jan,

The challenge with putting it only in the Service Order Management space is that is also applies to plan and build - which I recognise is not something that has enjoyed a lot of attention in TMF.

To a large extent it depends on whether you also use Resource Inventory for planned (future) state design, or only for service design recording.

Hi Pieter,

your statement "this 'design' is usually carried out in a Resource Inventory" is from the past implementations (I have similiar experience) but as far as I understand TMF standards and guidelines "this design" should be implemented in Service Order Management ODA Component. I believe reason for this is that SOM is loosely coupled with Resource Inventory in this case, which is a good thing. But here are far more experienced guys and I'm currious what they will say about your idea.

A common process that is employed - both in Plan and Build, and in Order to Activation, is that of Assign and Design where individual resources are allocated to a design based on manual processes, automated processes applying business rules etc.

As this 'design' is usually carried out in a Resource Inventory function, but can be called from both Service Fulfilment and Network Rollout processes, there arises a need for a separate API that enables the configuration of the requested design, results in a completed design with reserved (or even allocated) resources in the Resource Inventory.

TMF652 is about ordering a specific resource, and is far too granular - and in any event - you STILL need a process to orchestrate all the resources that need to assigned, along with the associated designs around configuration or routing.

How do we go about proposing a new API that enables the request, progress reporting and result retrieval of this function? 

A common process that is employed - both in Plan and Build, and in Order to Activation, is that of Assign and Design where individual resources are allocated to a design based on manual processes, automated processes applying business rules etc.

As this 'design' is usually carried out in a Resource Inventory function, but can be called from both Service Fulfilment and Network Rollout processes, there arises a need for a separate API that enables the configuration of the requested design, results in a completed design with reserved (or even allocated) resources in the Resource Inventory.

TMF652 is about ordering a specific resource, and is far too granular - and in any event - you STILL need a process to orchestrate all the resources that need to assigned, along with the associated designs around configuration or routing.

How do we go about proposing a new API that enables the request, progress reporting and result retrieval of this function? 

@Pieter Eksteen, I think the 'design' you refer to is a function of Resource Configuration and Activation (TMFC062).

The TMFC062 Component specification is still a work in progress.  In the current view it's Core Function produces:

• Resource Activation Management API (TMF702) 
• Resource Function Activation Management API (TMF664)
• Configuration Profile Management API (TMF783)

The Resource Activation APIs (702, 664) are the ones you are looking for.  The other (783) is a recently proposed API which introduces Configuration as a managed entity, something which may be created, updated, deleted as well as applied to, or derived from, existing entity instances.

As one of the primary authors of TMFC062 and TMF783 I would be quite interested in receiving feedback on our direction.

A common process that is employed - both in Plan and Build, and in Order to Activation, is that of Assign and Design where individual resources are allocated to a design based on manual processes, automated processes applying business rules etc.

As this 'design' is usually carried out in a Resource Inventory function, but can be called from both Service Fulfilment and Network Rollout processes, there arises a need for a separate API that enables the configuration of the requested design, results in a completed design with reserved (or even allocated) resources in the Resource Inventory.

TMF652 is about ordering a specific resource, and is far too granular - and in any event - you STILL need a process to orchestrate all the resources that need to assigned, along with the associated designs around configuration or routing.

How do we go about proposing a new API that enables the request, progress reporting and result retrieval of this function? 

Thanks Vance,

I considered both TMF702 and TMF664 before posting my question.

The challenges are 2 fold:

1. A design consists of multiple resources, not a single one - think the selection of all the resources (or resource types) from cell-site antenna to backhaul connection point.
2. Both 664 and 702 deal with an 'already-known' resource type etc., and design is about deciding which resources to use.

I have not looked at 783 - where can I find some details?

@Pieter Eksteen, I think the 'design' you refer to is a function of Resource Configuration and Activation (TMFC062).

The TMFC062 Component specification is still a work in progress.  In the current view it's Core Function produces:

• Resource Activation Management API (TMF702) 
• Resource Function Activation Management API (TMF664)
• Configuration Profile Management API (TMF783)

The Resource Activation APIs (702, 664) are the ones you are looking for.  The other (783) is a recently proposed API which introduces Configuration as a managed entity, something which may be created, updated, deleted as well as applied to, or derived from, existing entity instances.

As one of the primary authors of TMFC062 and TMF783 I would be quite interested in receiving feedback on our direction.

A common process that is employed - both in Plan and Build, and in Order to Activation, is that of Assign and Design where individual resources are allocated to a design based on manual processes, automated processes applying business rules etc.

As this 'design' is usually carried out in a Resource Inventory function, but can be called from both Service Fulfilment and Network Rollout processes, there arises a need for a separate API that enables the configuration of the requested design, results in a completed design with reserved (or even allocated) resources in the Resource Inventory.

TMF652 is about ordering a specific resource, and is far too granular - and in any event - you STILL need a process to orchestrate all the resources that need to assigned, along with the associated designs around configuration or routing.

How do we go about proposing a new API that enables the request, progress reporting and result retrieval of this function? 

@Pieter Eksteen,

Please consider the examples illustrated in the TMF664 API User's Guide:

The examples in TMF664 are sourced from TR255:

Resource Functions not only support the Composite/Atomic pattern but include additional properties for connectionPoint (input/output), connectivity (topology) and activationFeature (declarative configuration).

Thanks Vance,

I considered both TMF702 and TMF664 before posting my question.

The challenges are 2 fold:

1. A design consists of multiple resources, not a single one - think the selection of all the resources (or resource types) from cell-site antenna to backhaul connection point.
2. Both 664 and 702 deal with an 'already-known' resource type etc., and design is about deciding which resources to use.

I have not looked at 783 - where can I find some details?

@Pieter Eksteen, I think the 'design' you refer to is a function of Resource Configuration and Activation (TMFC062).

The TMFC062 Component specification is still a work in progress.  In the current view it's Core Function produces:

• Resource Activation Management API (TMF702) 
• Resource Function Activation Management API (TMF664)
• Configuration Profile Management API (TMF783)

The Resource Activation APIs (702, 664) are the ones you are looking for.  The other (783) is a recently proposed API which introduces Configuration as a managed entity, something which may be created, updated, deleted as well as applied to, or derived from, existing entity instances.

As one of the primary authors of TMFC062 and TMF783 I would be quite interested in receiving feedback on our direction.

A common process that is employed - both in Plan and Build, and in Order to Activation, is that of Assign and Design where individual resources are allocated to a design based on manual processes, automated processes applying business rules etc.

As this 'design' is usually carried out in a Resource Inventory function, but can be called from both Service Fulfilment and Network Rollout processes, there arises a need for a separate API that enables the configuration of the requested design, results in a completed design with reserved (or even allocated) resources in the Resource Inventory.

TMF652 is about ordering a specific resource, and is far too granular - and in any event - you STILL need a process to orchestrate all the resources that need to assigned, along with the associated designs around configuration or routing.

How do we go about proposing a new API that enables the request, progress reporting and result retrieval of this function? 

A common process that is employed - both in Plan and Build, and in Order to Activation, is that of Assign and Design where individual resources are allocated to a design based on manual processes, automated processes applying business rules etc.

As this 'design' is usually carried out in a Resource Inventory function, but can be called from both Service Fulfilment and Network Rollout processes, there arises a need for a separate API that enables the configuration of the requested design, results in a completed design with reserved (or even allocated) resources in the Resource Inventory.

TMF652 is about ordering a specific resource, and is far too granular - and in any event - you STILL need a process to orchestrate all the resources that need to assigned, along with the associated designs around configuration or routing.

How do we go about proposing a new API that enables the request, progress reporting and result retrieval of this function? 

A common process that is employed - both in Plan and Build, and in Order to Activation, is that of Assign and Design where individual resources are allocated to a design based on manual processes, automated processes applying business rules etc.

As this 'design' is usually carried out in a Resource Inventory function, but can be called from both Service Fulfilment and Network Rollout processes, there arises a need for a separate API that enables the configuration of the requested design, results in a completed design with reserved (or even allocated) resources in the Resource Inventory.

TMF652 is about ordering a specific resource, and is far too granular - and in any event - you STILL need a process to orchestrate all the resources that need to assigned, along with the associated designs around configuration or routing.

How do we go about proposing a new API that enables the request, progress reporting and result retrieval of this function? 

A common process that is employed - both in Plan and Build, and in Order to Activation, is that of Assign and Design where individual resources are allocated to a design based on manual processes, automated processes applying business rules etc.

As this 'design' is usually carried out in a Resource Inventory function, but can be called from both Service Fulfilment and Network Rollout processes, there arises a need for a separate API that enables the configuration of the requested design, results in a completed design with reserved (or even allocated) resources in the Resource Inventory.

TMF652 is about ordering a specific resource, and is far too granular - and in any event - you STILL need a process to orchestrate all the resources that need to assigned, along with the associated designs around configuration or routing.

How do we go about proposing a new API that enables the request, progress reporting and result retrieval of this function?