Open APIs

Hi,Hi,
We are able to map our Characteristic or group of characteristics leveraging the proposed structure using valueType of "string" or "object"

Where we have issues are around Features. For us a feature is a "thing" that is actionable. 
We would have something like: 
- serviceCharacteristic
For complex feature structure (with characteristic), we would have something like: 
- serviceCharacteristic
Looking for some feedback if we are taking the right approach
Regards

------------------------------
Stephane AH-KO
CGI Info Systems Management Consulting Inc.
------------------------------

Hi,

as you correctly state your features is usually modeled a a seperate CFS.
You fail to explain why this modeling doesn't suit you.

Regards

------------------------------
Koen Peeters
Ciminko Luxembourg
------------------------------

Hi all

I don't think that there is one right or wrong answer for this.

But, to my understanding, the Product/Service/Resource entity reflects the state and not the action. For the action, we have ProductOrder/ServiceOrder/ResourceOrder - in these Orders we have the OrderItem that includes action. So to add a feature, you would model the feature as a Service in the catalog, and then issue a ServiceOrder including an OrderItem with action add for this Service. To remove the feature, use an OrderItem with action remove.

As an alternative approach for features that don't have characteristics, you could model the feature itself as a characteristic of type Boolean; value true would cause the feature to be active and value false would cause the feature to be inactive. I don't like this approach so much, but I can understand why some people would find it attractive.

Hope it helps.

------------------------------
Jonathan Goldberg
Amdocs Management Limited
------------------------------

Original Message:
Sent: Jun 29, 2019 06:42
From: Koen Peeters
Subject: TMF641 - Handling Service Feature

Hi,

as you correctly state your features is usually modeled a a seperate CFS.
You fail to explain why this modeling doesn't suit you.

Regards

------------------------------
Koen Peeters
Ciminko Luxembourg
------------------------------

Thanks!

------------------------------
CETPA Infotech
CETPA INFOTECH
------------------------------

Original Message:
Sent: Jun 30, 2019 07:53
From: Jonathan Goldberg
Subject: TMF641 - Handling Service Feature

Hi all

I don't think that there is one right or wrong answer for this.

But, to my understanding, the Product/Service/Resource entity reflects the state and not the action. For the action, we have ProductOrder/ServiceOrder/ResourceOrder - in these Orders we have the OrderItem that includes action. So to add a feature, you would model the feature as a Service in the catalog, and then issue a ServiceOrder including an OrderItem with action add for this Service. To remove the feature, use an OrderItem with action remove.

As an alternative approach for features that don't have characteristics, you could model the feature itself as a characteristic of type Boolean; value true would cause the feature to be active and value false would cause the feature to be inactive. I don't like this approach so much, but I can understand why some people would find it attractive.

Hope it helps.

------------------------------
Jonathan Goldberg
Amdocs Management Limited
------------------------------


Original Message:
Sent: Jun 29, 2019 06:42
From: Koen Peeters
Subject: TMF641 - Handling Service Feature

Hi,

as you correctly state your features is usually modeled a a seperate CFS.
You fail to explain why this modeling doesn't suit you.

Regards

------------------------------
Koen Peeters
Ciminko Luxembourg

Thanks all for your answers

@Koen Peeters, our logic to differentiate if a "thing" is a another CFS or a feature of a CFS, is to compare that "thing" to the CFS and check if it can leave without the CFS. Depending on the answer, it's a CFS or a feature.
We looked at the option to have all our features be CFS.

• Just for the Voice CFS, we would end up with more than 60 CFS just to represent the Voice service itself.
• We would also require to introduce a concept of CFS hierarchy to link the (Feature) CFS to the main Voice CFS.
• Finally, the PSR hourglass concept would not work anymore since the CFS layer would not be the thinner layer anymore​​.

@Jonathan Goldberg. We looked at the option of using boolean characteristic as well. We abandoned for few reasons reason​s:

• For every Voice CFS creation, there would be more than 60 characteristics defaulted to 'false'
• The model works well for simple boolean structure, less for complex structure

At the end, we chose a model between the 100% CFS and the 100% characteristics, with the concept of Feature. The concept of feature works well as well with our inventory system which provides the "Configuration Item" capability (Config Items are "objects" that can be assigned or unassigned under a CFS). Our gap is with the TMF Model.
We are at the moment hesitating between 2 options:

• Introducing a new "Feature" object child of "ServiceRestriction". "Characteristic" would be child of "ServiceRestriction" and "Feature"
• Extending the "Characteristic" object with an attribute "action" and/or a type reflect the fact it's a Feature/capability

Regards

------------------------------
Stephane AH-KO
CGI Info Systems Management Consulting Inc.
------------------------------

------Original Message------

Thanks all for your answers

@Koen Peeters, our logic to differentiate if a "thing" is a another CFS or a feature of a CFS, is to compare that "thing" to the CFS and check if it can leave without the CFS. Depending on the answer, it's a CFS or a feature.
We looked at the option to have all our features be CFS.

• Just for the Voice CFS, we would end up with more than 60 CFS just to represent the Voice service itself.
• We would also require to introduce a concept of CFS hierarchy to link the (Feature) CFS to the main Voice CFS.
• Finally, the PSR hourglass concept would not work anymore since the CFS layer would not be the thinner layer anymore​​.

@Jonathan Goldberg. We looked at the option of using boolean characteristic as well. We abandoned for few reasons reason​s:

• For every Voice CFS creation, there would be more than 60 characteristics defaulted to 'false'
• The model works well for simple boolean structure, less for complex structure

At the end, we chose a model between the 100% CFS and the 100% characteristics, with the concept of Feature. The concept of feature works well as well with our inventory system which provides the "Configuration Item" capability (Config Items are "objects" that can be assigned or unassigned under a CFS). Our gap is with the TMF Model.
We are at the moment hesitating between 2 options:

• Introducing a new "Feature" object child of "ServiceRestriction". "Characteristic" would be child of "ServiceRestriction" and "Feature"
• Extending the "Characteristic" object with an attribute "action" and/or a type reflect the fact it's a Feature/capability

Regards

------------------------------
Stephane AH-KO
CGI Info Systems Management Consulting Inc.
------------------------------

Folks interesting discussion  Obaservations
This grouping of characteristics has come up in the ODA And ZOOM work.and clearly needs formally documenting. 
The model needs to be applicable at PSR levels in self similar way.and support atomic compositevpatterns. Catalyst Work we have on 5G GST  confirms this. 
SID currently has concept called Resource Function but name is deceptive as only applies to PS and is not atomic composite
SID has concept of Feature and Feature Group in Gb9222 Logical and compound Resource computing and software which is modelled formally as Configuration Feature. ODA has opened a number  SID Crs to clean up this modelling inconsistencies across PSR  Can add the CR numbers later but would be good to get wider input. Expectation is we will start on resolving these modelling matters on SID call starting Thurs 11th July




------------------------------
Dave Milham
TM Forum Chief Architect, TM Forum
------------------------------

Original Message:
Sent: Jul 02, 2019 08:28
From: Stephane AH-KO
Subject: TMF641 - Handling Service Feature

Thanks all for your answers

@Koen Peeters, our logic to differentiate if a "thing" is a another CFS or a feature of a CFS, is to compare that "thing" to the CFS and check if it can leave without the CFS. Depending on the answer, it's a CFS or a feature.
We looked at the option to have all our features be CFS.

• Just for the Voice CFS, we would end up with more than 60 CFS just to represent the Voice service itself.
• We would also require to introduce a concept of CFS hierarchy to link the (Feature) CFS to the main Voice CFS.
• Finally, the PSR hourglass concept would not work anymore since the CFS layer would not be the thinner layer anymore​​.

@Jonathan Goldberg. We looked at the option of using boolean characteristic as well. We abandoned for few reasons reason​s:

• For every Voice CFS creation, there would be more than 60 characteristics defaulted to 'false'
• The model works well for simple boolean structure, less for complex structure

At the end, we chose a model between the 100% CFS and the 100% characteristics, with the concept of Feature. The concept of feature works well as well with our inventory system which provides the "Configuration Item" capability (Config Items are "objects" that can be assigned or unassigned under a CFS). Our gap is with the TMF Model.
We are at the moment hesitating between 2 options:

• Introducing a new "Feature" object child of "ServiceRestriction". "Characteristic" would be child of "ServiceRestriction" and "Feature"
• Extending the "Characteristic" object with an attribute "action" and/or a type reflect the fact it's a Feature/capability

Regards

------------------------------
Stephane AH-KO
CGI Info Systems Management Consulting Inc.
------------------------------

Folks good discussion 
In ODA Production ZOOM we have been looking at this general topic of grouping of characteristics. We have come to similar conclusions that we need a common model at P/S/R level and support and atomic composite pattern.
Looking at GB922  Logical Resource Business Entity Definitions – Computing and Software The SID has a Resource Function which actually only works for P/S  and is nt supporting composite pattern.
It also has Feature and feature group modelled as ConfigurationFeature
The thinking is that we need a more consistent set of pattern and afew CRs have been opened with the SID to address these points ( also to support model driven automated onboarding.

1. FP-836Create classes representing specialization of the general "Function" concept
2. FP-835Create "Function" as a general concept
3.  FP-832Clarify definition of "SoftwareResourceSpecifict
4. FP-837Deprecate "Feature" and "FeatureGroup"

 

------------------------------
Dave Milham
TM Forum Chief Architect, TM Forum
------------------------------

Original Message:
Sent: Jul 02, 2019 08:28
From: Stephane AH-KO
Subject: TMF641 - Handling Service Feature

Thanks all for your answers

@Koen Peeters, our logic to differentiate if a "thing" is a another CFS or a feature of a CFS, is to compare that "thing" to the CFS and check if it can leave without the CFS. Depending on the answer, it's a CFS or a feature.
We looked at the option to have all our features be CFS.

• Just for the Voice CFS, we would end up with more than 60 CFS just to represent the Voice service itself.
• We would also require to introduce a concept of CFS hierarchy to link the (Feature) CFS to the main Voice CFS.
• Finally, the PSR hourglass concept would not work anymore since the CFS layer would not be the thinner layer anymore​​.

@Jonathan Goldberg. We looked at the option of using boolean characteristic as well. We abandoned for few reasons reason​s:

• For every Voice CFS creation, there would be more than 60 characteristics defaulted to 'false'
• The model works well for simple boolean structure, less for complex structure

At the end, we chose a model between the 100% CFS and the 100% characteristics, with the concept of Feature. The concept of feature works well as well with our inventory system which provides the "Configuration Item" capability (Config Items are "objects" that can be assigned or unassigned under a CFS). Our gap is with the TMF Model.
We are at the moment hesitating between 2 options:

• Introducing a new "Feature" object child of "ServiceRestriction". "Characteristic" would be child of "ServiceRestriction" and "Feature"
• Extending the "Characteristic" object with an attribute "action" and/or a type reflect the fact it's a Feature/capability

Regards

------------------------------
Stephane AH-KO
CGI Info Systems Management Consulting Inc.
------------------------------